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Background 

Field of the Invention 

This invention pertains in general to electronic commerce and in particular to a method 
10 and system for conducting electronic payment transactions via the Internet. 

Background of the Invention 

Electronic commerce conducted over the Internet has become increasingly important 
over the last decade. Online merchants offer goods and services for sale or rent including 

15 physical objects such as compact disks, books, and clothing, and intellectual property such as 
streaming music and movies and electronic books. Physical items may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, in contrast, 
may be delivered to the customer by allowing a download via the file transfer protocol 
("FTP"), providing the customer with an access key, establishing a telnet session, or through 

20 some other form of electronic delivery. 

Typically, these goods and services are displayed on the merchant's web site and a 
prospective customer views, selects, and purchases the goods using web browsing software 
such as NETSCAPE NAVIGATOR* The customer usually pays for a product by establishing 
a secure connection with the merchant's web server and transmitting payment information, 

25 such as a credit card number, to the merchant. The merchant then uses back-end processing to 
verify the payment information and receive payment. For example, the merchant may use a 
secure telephone line or network link to contact the credit card issuer before accepting the 
customer's order. Eventually, the merchant and credit card issuer settle payment and the 
merchant delivers the product or service to the customer. 

30 A difficulty with the above-described scenario is that each merchant must implement an 

inventory and payment database and a payment acceptance and verification system. For 
example, the merchant must establish and maintain a database tracking sales, delivery, and 
payment information and product inventories in order to support the electronic commerce 
system. There is significant cost and complexity in maintaining this database, including the 

35 difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by 
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The United Parcel Service has ac- 
tivated the first nationwide mo- 
bile data service using cellular 
technology, permitting the 
company to transmit delivery infor- 
mation from its 50,000 delivery vehi- 
cles for immediate customer access. 

UPS created the system by form- 
ing the first alliance of fifty public 
cellular carriers throughout the 
country to provide a common data 
service, ail connecting with UPS's 
own private global telecommunica- 
tions network. UPSnet The sysiem, 
which was implemented at a cost of 
about 3150 million, is the largest of 
its kind in the world. UPS selected 
cellular over the other network alter- 
natives because it provided the most 
extensive geographic coverage, high- 
est reliability, and potential for fu- 
ture upgrades. 

The cellular alliance features 
McCaw Cellular Communications, 
Contel Cellular, GTE Mobilnet (for- 
merly known as GTE Mobile Com- 
munications), PacTe! Cellular, and 
Southwestern Bell Mobile Systems, 
ail competitors in the cellular indus- 



try. These firms enlisted fifty additional 
carriers to help UPS extend its immedi- 
ate tracking network across the United 
States. 

Comprehensive Tracking 

The mobile data service is the founda- 
tion for the company's comprehensive 
tracking system — UPS TotalTrack, which 
provides immediate delivery information 
on bar coded air and ground packages. 
This information was not previously 
available until the day after delivery. 

UPS is the only parcel delivery com- 
pany able to digitally capture both pack- 
age information and the customer's sig- 
nature through a custom-built hand held 
computer called the DIAD (Delivery In- 
formation Acquisition Device). Access to 
the cellular system is activated when the 
UPS driver inserts the DIAD into the ve- 
hicle's unique transmitter (DIAD Vehi- 
cle Adapter). From there, the tracking 
information is uploaded through the cel- 
lular system and UPSnet to the UPS Data 
Center in Newjersey. The in-vehide 
equipment and logistical support came 
from Motorola, Inc, with installation by 
UPS*s automotive mechanics. 



This cellular network pro- 
vides the connection between 
UPS vehicles and the UPSneL 
These systems are created to be 
fail-safe with cellular redundan- 
cies, dual access to UPSnet, and 
multiple connections to the data 
system. 

The cellular-based wireless 
data service provides immediate 
access to delivery information for 
more than 1 million UPS daily 
pickup customers. It also provides 
more extensive geographic cover- 
age than any mobile communica- 
tion alternative. 

The UPS mobile data system 
includes several technical innova- 
tions designed to adapt the voice- 
oriented cellular systems for data 
transmission. Error-correction com- 
munication protocols are used to 
ensure error-free message delivery. 
And cellular carriers' switching sys- 
tems are directly connected to UP- 
Snet to reduce the duration and 
cost of data calls. The carriers also 
developed a billing system consoli- 
dating all carrier charges into a sin- 
gle UPS bill and 



On The Fast Track 
with TotalTrack: 
UPS Deploys 
Mobile 
Data Service 



'Henfylowie* 




Henry TowU is a freelance writer who lives and works in New York Gty. 



DOCUMENT DEHVEIY WORtO 



APtlt/MA Y 19 9 3 



established a unified carrier help desk ihae 
resolves service problems quickly. 

With ihe ceUuJar communications 
technology. UPS Tota/Track can provide 
detailed information on such things as 
pickup date, scheduled date of delivery 
status of package, same day verification of 
delivery, and the name of the person who 
receded the package. It is available bv call- 
trig a tol^free Tracking Hot Line (1-500- 
457-4022) which is staffed rwentvfcur 
hours a day, seven days a week. 

New Levels of Service 



In addmon to providing customers with 
immediate tracking information. ITS is 
able to provide customers with 
MaxiShip, a PObased automated 
shipping system designed for cus- 
tomers with high package volume 
and the need for fast package pro- 
cessing. Using VPSprovided soft- 
ware, the system automatically 
rates and zones packages, prepares 
packages requiring special services, 
such as CO.D. and Delivery Con- 
firmation, and creates userdefined 
management reports, 

UPS has also created a new 
level of service that provides guar- 
anteed threeday delivery and im- 
mediate package tracking. Called 
UPS 3 Day Select, it is the first service of its 
kind to be offered in the small package dis- 
tribution industry. UPS 3 Day Select was 
developed primarily for longer-distance 
shippers who need time-definite delivery 
and higher levels of information. The ser- 
vice is available to anv shipper for interstate 
delivery throughout the 48 contiguous 
states and is priced between the company's 
traditional ground and air express services. 

UPS 3 Day Select can be used when a 
long distance shipment must be delivered 
raster than regular UPS ground service. 
Customers are provided with special bar- 
coded labels, each with a unique number 
that is scanned into the tracking system at 
key points during transit. For immediate 
updates on a shipment's status, customers 
can call the Tracking Hot line and pro- 
vide UPS with the tracking number. 

The cellular system developed by 
UPS is considered the most comprehen- 
sive wireless data transmission architecture 



available today. It covers more area and is 
more reliable than any other type of mo- 
bile communication. 

Technology has also provided UPS 
Key platforms for expanding its customer 
services globally. In 1988 UPS moved into 
the overseas market with its global elec- 
tronic data communications network, UP- 
Snec to serve as the information process- 
ing pipeline for international package 
processing and delivery. UPSnet now has 
more than 500,000 miles of lines and links 
more than 1,300 UPS distribution sites in 
forty^x countries. UPS is leasing excess 
lines through a UPS owned company, 
UPS Telecommunications. 

In 1991 UPS's International Ship- 



Cellular industry Foasafa Glance 

Sfnf^ m - 00 0aoDef m > 1983 < ** to cellular 
sysfem Degan operating in Oiiccgo. 

Subscribers. 10 million, as of November 23. 1992. 

Growth. Currency adding 222,000 new cellular users 
every monfh, or roughiy^oo every day oSSter 
even years the inausfr^piooed from 203 600 



Revenue. Approximately $7.2 biJfionoyear. 



ment Processing System (ISPS) received 
the COMPLTIXRWORLD/Smiihsonian 
award for innovation in information tech- 
nology. 

Smart Scanning 

Since 1989. ISPS has acquired a universal 
accounting system and an enhanced 
tracking system that can follow the move- 
ment of a package in transit. Everv inter- 
naoonal package now undergoes "smart 
scanning" which takes tracking to the 
next step by determining through bar 
code technology not only where the pack- 
age is supposed to be, but where it actual- 
ly is. The system also provides for re-rouc- 
mg of packages and notifies interim and 
ftnal UPS destinations if a package is ear- 
V. laie, or routed to the wrong destina- 
tion. 

UPS has long been interested in Elec- 
*°n>c Data Interchange (EDI), the com- 



puter-texomputer exchange of inibrma- 
wn. The company has the most extensive 
EDI interaction with foreign customs 
clearance houses in the world, with stan- 
dard-based systems in place or being devel- 
oped in more than twenty countries EDI 
is allowing UPS to streamline procedures 
eliminate paper, and conserve time and ' 
money. UPS is now able to electronically 
disseminate clearance and delivery infor- 
mation from the customer's computer, to 
the destination customs agency, to the ' 
consignee. To support these technology 
systems the UPS maintains two data ceo- 
ters. in Mahwah and Paramus, New Jersey. 

LTS is not only a global delivery net- 
work, but a telecommunications company 
with its own fiber-optic network and 
its own communications satellite. 
Because of its recent interest in us- 
ing high technology to deliver pack- 
ages, it is easy to forget that the com- 
pany was founded in 1907 in Seattle. 
Mow headquartered in Atlanta, LTS 
has more than 273,000 employees, 
delivers 1 1.5 million parcels arid 
documents per day, owns 1 16,000 
chicles and 197 jet aircraft Its ser- 
vice area includes more than 185 
countries and territories, has a daily 
customer base of 1.2 million ship- 
per*, and last year earned $16.5 bil- 
lion in revenues. 
LTS has 3,000 employees involved 
just in technology, owns six mainframe 
computers, 250 minicomputers, and 
41300 PCs compari vwide. It also has 600 
LANs and 18.000 connected workstations, 
100 packet switching nodes worldwide, 
and 465.000 miles of dedicated cable cir- 
cuitry. 

LTS's creation of Tota/Track is seen 
both as a major advance in development 
of the cellular industry and encourage- 
ment for the industry itself to undertake 
other advances in data services. 

The United Parcel Service is in the 
package distribution business and also the 
information business reporting on its 
package business. The ads that UPS is run- 
ning on behalf of TotaJTrack state that 
"now there'sjust one thing that travels 
faster than a UPS package. And that's 
news or it. " A happy, and competitive, sate 
of affairs. 
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Customer Service Agreement 



You, the Customer, and PC Foods mutally agree to be bound by the 



PC Foods agrees to receive your order, purchase only items 
listed, and deliver them to your designated place of delivery 
within two hours of the time you list on your order as the 
preferred delivery time. This two hour window is the delivery 
time frame. 

All orders received by midnight (est) will be delivered the next 
day within the delivery time frame unless an alternate delivery 
date is specifically requested. Requests for same day delivery 
will be accommodated in most circumstances for an additional 
fee. 

The Customer agrees to be liable for the cost of groceries and 
service fees for the items requested and futher agrees to make 
full payment at the time of delivery. This payment includes the 
grocery total and applicable service fees. PC Foods will accept 
cash, credit card (Visa, Master Card, American Express), 
money orders, or personal checks. A returned check fee of 
$25.00 will be assessed for all returned checks, regardless of 
reason. In the instance PC Foods receives two returned 
checks, a cash-only basis will be invoked. 

The Customer agrees to be available and accept the grocery 
purchase during the delivery time frame. An non-deliverability 
charge of $1 0.00 will apply if at the expiration of 20 minutes 
past the delivery time frame you or your designate are not 
available to accept the purchase and render full payment. A 
second delivery will be attempted during the same day at a 
reasonable time determined by PC Foods. PC Foods is not 
liable for the freshness or quality of the order past the delivery 
time frame. Due to the perishable nature of the items being 
delivered, when the Customer is not available to receive the 
groceries on the second delivery attempt, the Customer agrees 
to still be liable for all costs and service fees. 



following terms and conditions: 



If the Customer fails to pay at the time of delivery or if the 
customer is not available to receive the delivery, the Customer 



Customer service Agreemeni 



agrees to bear and pay collection fees and legal fees 
reasonably necessary to collect the original principal amount 
due to PC Foods. 

If PC Foods cannot for any reason meet our obligation for your 
individual order, all reasonable efforts will be made to notify 
you prior to delivery and you may elect to cancel the order 
without any assessed service fees. 

In addition to the above stated contract between PC Foods and 
you the customer governing the terms and conditions of 
receiving merchandise, the following conditions apply to the 
use of the Ordering System. The PC Foods grocery ordering 
system is the sole property of PC Foods, Inc. You may use this 
proprietary system only after completing a registration form. All 
logos, slogans, operational characteristics, posted articles, and 
code - including publically available HTML, Text, JavaScript, bit 
maps, and the "look & feel" are copyright of PC Foods, Inc. and 
Walker Consulting. You may not publish, reproduce, reverse 
engineer, copy, or create derivative works of the PC Foods 
Ordering System. 

By clicking on the "I Agree" button the customer agrees to be 
liable for any use of the PC Foods ordering system by or 
through that customers assigned account number. You the 
customer also agree to inedemnify PC Foods for any such use. 
PC Foods may alter any terms of this agreement in its sole 
descretion by giving the customer reasonable notice. The 
customer will be deemed to have accepted such changes 
through continued use of the PC Foods ordering system. The 
customer may terminate this agreement by giving PC Foods 
reasonable notice and agrees to be liable for any charges 
incurred. Finally, the customers agrees to provide truthful and 
accurate information on the registration agreement. Failure to 
do so will lead to the termination of your account and possible 
legal action for violation of these agreement terms. 

HAVING READ AND UNDERSTOOD IN FULL THE 
FOREGOING REGISTRATION & CUSTOMER SERVICE 
AGREEMENT, CONTINUE WITH THE REGISTRATION 
PROCESS BY CLICKING ON Start Registration IN THE LEFT 
FRAME. YOU WILL BE ASK TO SIGNIFY YOUR 
AGREEMENT WITH THESE TERMS BY SELECTING / 
AGREE AFTER FILLING OUT THE REGISTRATION FORM. 
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I. ABSTRACT 

Japan's economy started to slow down in 1991. 
during this period overall transportation demands were 
down These difficult times affected the Door to Door 
Parcel Service (DTD), however, we see the bus.ness 

^Foltowing the lead of the U.S.. Japans DTD 
started IS years ago. Of the 40 companies which 
started in the DTD industry only a few survived 
Amongst these companies. Yamato Transport Co Ltd 
(YTC) Japanese Post Office, and Nippon Express Co.. 
Ltd emerged as the industry leaders and today. 
command a virtual monopoly. According to the 1991 
statistics of the Japanese Ministry of Transport these 
three companies handled 78% from the total 15 Mien 
parcel volume. YTC. the Japanese pioneer and leader, 
delivered 0.5 billion parcels in 1991. 

Japan has 39.000 truck companies and their fleet 
consist of ordinary trucks offered by the manufactures. 

I would like to explain the history of our custom 
made DTD-Takkyubin truck and its information 

technoloqy. * 

"Kuroneko Yamato Takkyubin" is the name of our 
consumer friendly DTD service, offering next day 
delivery, flat rate, and equal service to anybody 
anywhere. YTC uses box containers (Un I Load 
System) and Logistic Management to standardize aH 
SLal work. Our catch phrase is "Call Yamato for a 
pickup today, to deliver tomorrow" and our employee 
motto is "Service first and bottom-up-management . 
Following our mottos we developed the Takkyubin 
truck Every year, improvements, especially in moNity 
and delivery functions, are added to our InfonrcM. 
Integrated radio and YTC network, combmed with 
customized functionality, all part of the Takkyubin truck. 

Today Japanese trucks are made specifically to 
transport goods. No truck manufacturer offers a 
modern truck with advanced integrated communication 
technology.i.e. an office on wheels. This is where YTC 
stepped in and implemented a technologically 
advanced truck, which allowed us to lead the industry. 

» 



II. DTD PARCEL DELIVERY 

In 1977 YTC pioneered Japanese DTD. By 1991 
the total industry, including Post Office services 
delivered about 1.53 billion parcels annually. 

Parcels Delivered / Annual Increase 
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YTC. Nippon Express Co., Ltd. and the Post Offic 
hold a market share of 74%. The parcel volurm 
increases annually and the three companies have . 
virtual DTD-monopoly. 

Annual Parcel Delivery 




Figure 2 
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In the United States where the business started 10 
years earlier than in Japan, companies such as United 
Parcel Service (UPS). DHL, and Federal Express carry 
more than three billion parcels annually. They 
expanded their business world-wide and share now 
more than 60% of Japan's international parcel volume. 
YTC started a joint venture with UPS. DHL founded 
DHL Japan with support from Japan Airline and 
Lufthansa, and Federal Express bought a Japanese 
transport company. 

U.S. DTD - Parcels are picked up by truck and 
delivered to the local hub close to the airport. A hub is 
basically a truck terminal with a high speed sorting 
machine. Parcels which are to be delivered over long 
distances, are flown to Super Hubs via company plane. 
UPS has its Super Hub in Louisville. KY, and Federal 
Express in Memphis, TN. The last parcels arrive 
around midnight. All the sorting is done in a few 
hours. The parcels are then flown to their destination 
hub. to be picked up by trucks and delivered early in 
the morning. This system is called Hub and Spokes. 




Hub and Spokes 

(hub) \jL° : 

V— ■ y Orfice 



Airplane 

Truch 
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Figure 3 





Figure 4 Figure 5 

According to business reports from UPS and 
Federal Express, their air fleet consists of more than 
300 large body planes. Both companies Super Hubs 
are in the central part of the U.S., and the time zones 
are used effectively. The dynamic super hub system 
has been very successfully implemented. 

Japan's land area is 380,000 square kilometers 
(146.000 square miles), which equates to be 1/25 of 
the U.S.. Japan has four main islands and over 4.000 
smaller islands. The boomerang shaped archipelago 
stretches 2,800 kilometers from north to the south-west. 
The majority of the population lives in the densely 
populated metropolitan areas of Tokyo and Osaka, 
barely 500 kilometers (312 miles) apart. Between these 
two cities the parcel volume is extremely high. On the 



other hand, the parcel volume for the^ spars* 
populated poles of the country^ is very low. 4 % 

Due to Japan's unique geographic ai 
demographic features, the american Hub and Spo 
system with its heavy reliance on cargo planes coi 
not be implemented and thus a considerably differs 

DTD derived. 

In' 1991, according to Japan's Distribute 
Statistics, the* total weight of parcels delivered 
domestic transportation was 6.3 billion tons. T 
trucks share is 5.7 billion tons or 90%. Multiplying t 
weights by the delivery distances, trucks account 
more than 50% weight-distance. Maritime and i 
transportation accounts for almost all other part 
cargo movement, air cargo accounts for less than 1°/ 

Japan has 5,000 kilometers (3.125 miles) 
expressways covering the country. Tunnels a 
bridges for rails and expressways connect Honshu w 
Hokkaido, Shikoku, and Kyushu. The excellent ro 
and track infrastructure is capable of handling lar 
volumes of cargo. YTCs transportation system tak 
advantage of this by utilizing 11 - 15 ton trucks 
ensure fast parcel delivery. The most striki 
difference between the U.S. counterparts, is the virti 
aversion of planes. YTC has a hub in every large ct 
a total of 64. Most hubs have 63 truck routes to 
other hubs. One circum-route provides additioi 
support. In Japan, this system is called rosenbin. T 
actual rosenbin truck routes exceed 2.200. 



Rosenbin Routes 
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Figure 6 




Figure 7 

Around midnight rosenbin trucks leave for \ 
destination hubs where they arrive in the early mornu 
To increase efficiency the truck routes are support 
with airplanes, trains and piggybacks. Sorting is dc 
in a few hours and morning delivery starts. Each i r 
sized hub supports 20 to 25 pickup and deliv 
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.centers (YTC-Offices). From these centers. YTC 
delivers and picks up customer parcels. In addition, 
each center supports about 160 agencies for customer 
□arcel drop offs. A total of over 260.000 agencies are 
spread throughout Japan. Parcels are picked up. or 
for a lower rate can be dropped off at any agency. 
Each YTC-Office has its own fleet of Takkyubin trucks 
for pickup and delivery. Takkyubin. our trade name tor 
door to door service, delivers over 500 million parcels 
net year. Standard Takkyubin means next day 
delivery. To distinguish YTC from other companies 
Takkyubin provides special services. "Cool Takkyubin 
offers three different temperatures. 0 C. -5 C . and - 
18°C for food transport. "Golf Takkyubin" is door to 
qoff 'course service (pre-alerts golf course). Time 
Takkyubin" provides timed delivery and same day 
service and "UPS Takkyubin" is used for international 
service! These special services fetch premium fees 
their share reached 10%. This new generation of 
Takkyubins became an instant success. 

After more than 20 years of phenomenal growth, 
home to home deliveries are flattening. Business-Use. 
company to company or company to person ^dehvery 
is the latest market leader. Japan s short distances 
between cities allow truck service for next day 
deliveries. Most business correspondence use this 
service, taking advantage of parcel tracking. Grow* is 
strong and today it accounts for more than 50% of the 
Takkyubin deliveries. 

The first ten years of YTC's expansion were 
hampered by red tape. No specific DTD regulations 
were enacted, and YTC had to apply in every crty for 
an array of permits. The DTD industry grew ever larger 
and finally in 1989. the Japanese Government acted. 
The Ministry of Transport decided to revise heir 
regulations, for the first time in 45 years. After a long 
struggle. YTC was finally able to benefit from more 
business friendly regulations. 

The U S showed us the potential for a new kind 
of parcel delivery business by providing next day 
delivery, flat rate, and equal service for everybody 
anywhere. After implementing a system tailored to 
!a£ns specific needs, we repeated the U.S. success 
story. Today the size of Japan's DTD industry is only 
surpassed by the U.S.. 

III. TAKKYUBIN CUSTOM TRUCK 

YTC started as a regular truck freight company. 
Takkyubin deliveries were only a minor part of the 
business and regular trucks were used for ^ parcel 
delivery In 1979 one incident changed everything. A 
picture showing a brown UPS delivery truck, triggered 
the takkyubin truck revolution. YTC realized that a 
customized delivery truck would open the door for 
service performance unknown in Japan. 

At that time. UPS had a research facility designing 
customized delivery trucks, followed by successful 
production. Their study included handling, effective- 



ness safety and "human design". Inspired by their 
concept, the manager of YTC Fukupka Vehicl e Serv.ee 
Center built a prototype using old scrap car parts and 
presented it to Yamatos truck manu'actu^ Ou 
concept was "Effectiveness and Safety. Toyota Motor 
CorpoJation approached YTC and offered to bui d ve 
prototypes of a Takkyubin truck. In 1981. the first 
Takkyubin truck was delivered. The cost was i high. 
IboS tt.000.000 yen (480.000 U.S. dollars . Toyota 
realizing the potential of a new market, named I rt •Walk 
Trough Truck" and added it to it's product bm. The 
truck allowed the drrver to walk in upright position from 
he cabin to the cargo area. The first trucks had many 
critics A raw and sometimes annoying truck des.gn. 
corSined with unexperienced drivers Med to a bumpy 
«;t a rt However YTC's and Toyota's team spirit faced 
the change and eliminated problem by problem over 
K years Annual Takkyubin truck Productions now 
around 1.000. Out of 12.100 trucks YTC purchased. 
9.450 are currently in use all over Japan. 

The "Walk Through Truck" combines the drrver s 
cabin with the cargo area into one room. The truck* 
supplied with a high tech. low emission d.esel eng^e 
to P £eet tough t ^^^^S 

cabTn to the cargo area, and rear and side cargo door 
Sn be conveniently opened from inside or outs.de. Jn 
Tendance with "the concept 
Safetv" Toyota and YTC add or improve 20 features 
evfryVar Japanese automobile and transportation 
regulation are very strict and severely ^r the 
freedom on how to build the truck. &*yW* "J* 
nass a very stringent annual inspection. ine 
ZZJLTL* «o 9 ,he d«=u«y ,o 
trucks Naturally people from Toyota and YTO nave 
bee^ string with 'automobile and transportatjon 
agencies since the very beginning. Fasc.nated by the 
American UPS truck, relying on P^ r «f- 
improved the vehicle. Due to the burden of more 
restricts regulation, the Takkyub.n truck is no match 
to its UPS counterpart. Nevertheless the dream to 
make a perfect truck which pleases the drrver runs 
without polluting the environment, and still meets all 

^^^X of enwo— 
sound fuels. Prototypes of battery «nd methano 
powered cars are being developed with othe. 

COmP ££s S ' 21 200 vehicle s include 3.000 rosenbir 
trucked ffom the 17.000 dejivery vehicles . o wh. 
9.450 are Takkyubin trucks. YTC takes an active ro 
using their know-how and experience to neif 
manufactures of trucks to build better vehicles 

20 years ago. when I visited UPS in New York, th 
director persuaded me of the distinction of the UP- 
trucks and 1 was profoundly impressed about the 
excellence. 



373 



Takkyubin Truck 

.$2k Through Truck) manufactured by Toyota. 
SPECIFICATIONS 1991. MODEL (TOYOTA MOTOR 



DIMENSIONS (M) 


LENGTH 5.02 WIDTH 1.79 HEIGHT 2.9 


CLEARANCE 


0.85 H 


CARGO AREA (M) 


LENGTH 2.80 WIOTH 1.60 HEIGHT 1.7* 


CAPACITY WT 


2 TONS 


CAPACITY VOL 


7.79 CUB. M 


ENGINE 


2.977 CCM 


WHEELBASE 


2.50 M 


TURNING RAOIUS 


4.60 M 


TIRES 


FRONT 195-14-6 REAR 185-14-8 





or 



a 



CO 



-it 



ii 

-2 




374 



IV.. DTD INFORMATION SYSTEM 

"Kuroneko Yamato Takkyubin" is the name of our 
door to door delivery service. It operates from 8 a.m. 
to 8 p.m., 365 days of the year. The popular saying 
■Call Yamato for a pickup today, to deliver tomorrow", 
is used all over Japan to request Takkyubin service. 
We provide next day delivery to 99% of Japan. This 
service is controlled by a state of the art computer 
network. 

Every driver has a handheld computer (POS). 
Several phases of the parcel delivery are entered into 
the POS: the pickup, the arrival at the originating hub, 
the completion of sorting at the destination hub and 
the final delivery. This allows YTC to locate any parcel. 

Information is entered by the driver with his 
portable POS and is transmitted by a tele- 
communication network. Passing through the YTC 
sales offices's WS (work station) to the hub's mini 
computers, the data feeds into the mainframe 
computers in Tokyo and Osaka. 

The database in the mainframes are updated 
every 15 minutes. Parcel tracking for customer service 
is possible from 8 a.m. to 10 p.m. YTC calls this 
'Parcel Inquiry Service." The parcel's ID number, which 
is supplied on the invoice as an bar code, allows 
instant parcel tracking. 



Parcel Inquiry Screen 



1992/07/16 |4 : 4j : 04 ff 

rilMIIII IHCCMfi S C « £ £ K 



Off. Arri*. Cont.HO. Fl»o« £**1oy«t K**d«r 
0« t« Code Codt T**e loi-*> -Me -* 



900- 1214-9941 *ich-«« 07/17 45-10 30*09 10.00 049498 
Load Cont. 07/17 *S-00 2272080 0*4147 

Lo*d Trvcl 07/17 45-00 72:5* 2222040 453001 0*4147 

Arr. h«» 07/17 30-00 05:25 2222080 002122 



•NO 
S2M94 



Kii 20 itttuf 



W0 07/18 30-19 

Tiae POO 08/1B 30-19 



09:46 



0**245 
0**245 



321341 
321341 



Figure 9 

Any of YTC's truck drivers or 1.600 offices offer 
the customer instant parcel tracking. Customer service 
is at its best. 

Yamato System Development (YSD), to which I 
belong, is YTC Group's pivot computer company which 
handles all YTC Group's communication networks and 
information systems. YSD has Fujitsu and IBM main 
frame computers. These powerful computers are 
located in Tokyo and Osaka and are the backbone for 
database management and information communication 
networks. In case of an emergency, Tokyo and Osaka 
centers mutually maintain real-time backups, 24 hours, 



Sail loaa* Transportation Srsiei br Box Palette Cool j her 



CdStoaer Oitabase 



Telephone Operatioi 
Center 




Carry Back Report 





Deliver Report 








Parcel Unusual 






Information 







Figure 10 
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Figure 12 



365 days per year. Main networks have relay points all 
oyer Japan, using double NTT (Nippon Telegraph and 
Telephone) and NCC (New Common Carrier) high- 
speed digital circuits. Each line has at least one 
backup line. Every relay point, is connected with over 
1,600 centers, total communication line length is more 
than 242,000 kilometers (151,000 miles). 

In 1982 YSD's Value Added Network (VAN) 
service was the first to be certified by the Ministry of 
International Trade and Industry for public use. Today 
the system supports YTC and over 180 customers with 
over 13,000 terminals. In 1990. YSD installed a 
International Leased Line (High-speed digital circuit) 
from Tokyo to Los Angeles to start overseas network 
services. 

Recently. Matsushita (Panasonic) asked YSD to 
operate Electronic Data Interchange (EDI), so the trend 
is from VAN to EDI. 

Today, Yamato System Development is 19 years 
old has a capital of 1.8 billion yen. and 1,100 
employees. YSD also provides services outside of 
YTC. In 1991 65% of all sales income, which was 18.8 
billion yen, was generated from outside customers. 



Profits were a sound 1.1 billion yen. We have over 700 
system engineers in our development department. 
YSD has its own delivery business. Our eight 
distribution centers (warehouses), approved by The 
Ministry of Transport, have total area of 23.1 square 
kilometers (9.0 square miles). Approximately 30 trucks 
support the Distribution Operation Centers. 




Figure 14 
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YSD SYSTEMS 



1. Transportation Information Systems 

1 MCA Delivery Support Systems 

- Pickup Control System - Dispatch Management 

- Delivery Control System - Under Development 

- Driver Control System 

2 Hub Control Systems 

• Automated Sorting System 

- Unit Load System 

3 Digital Driving Pattern Monitors 

- Report Generator 

- Speed, Idle, Rpm, Weight tracking 

- Fleet Management System 

2. Delivery Monitoring Systems 

1 Delivery Status Monitoring System 

2 Delivery Volume Monitoring System 

3. Customer Information Systems 

1 Pre-Print Invoice System (Volume Customer) 

2 Customer Information System 

3 YSD Customized Systems by Business Types 

- Database Package for Home Business 

- Database Package for Mail Order Business 

- Charges Collect Support System 

4. Special Takkyubin Systems 

1 Cool Takkyubin Support System 

2 Book Takkyubin Support System 

3 Food Takkyubin Support System 

4 Time Takkyubin Support System 

5 Leisure Takkyubin Support System 
(Ski, Golf. Luggage) 

5. Application Software 

1 Accounting Packages 

2 Personal Resources Management Systems 

3 Business Management Systems 




Figure 16 
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V. TftUCK information systems 

Below are some examples of YTC's Information 
technology in relation with Takkyubin trucks. 

1. PICKUP WITH MCA 

Mufti Channel Access (MCA) is a two way 
communication radio system. 

Yamato has 260.000 agencies throughout Japan. 
Parcels can be dropped off at any YTC office or 
agency. Takkyubin trucks provide scheduled pickups 
for their agencies. Parcel drop offs are discounted at 
•100 yen per parcel. In urban areas YTC must prov.de 
superior pickup response for larger parcel volume in 
order to compete with other delivery serves. 
Takkyubin pickup requests by telephone are 
immediately transferred to the truck nearest the 
customer. Yamato doesn't want customers to wait. 
■No wait pickup- is the basic goal to beat the 
competition and this can only be achieved wrth the 
help of computer information systems. 

Before we had integrated network support the 
basic pickup procedure was as described below. A 
customer called and the operator had to wrrte the 
name, address, parcel quantity, time. etc. on a 
memorandum. After receiving several pickup orders 
the operator sorted them, and called the trucks dosest 
to pickup area. This system worked fine but wrth 
growing parcel volume problems occurred. The 
fallowings were the major problems we encountered: 

Errors happened because extensive customer 
information had to be written down for each new 
delivery. 

Between the busiest hours of 4 to 6 p.m. 
operators had to put customer on hold. MCA 
communications were also overloaded, so many 
operators couldn't get in touch with the truck 
drivers which caused delays in pickups. 
YTC safety regulations required drivers to pull over 
to write down the operators information. Very 
inefficient. 

To solve these three problems Yamato had 
developed a computer system to perform the following: 

(1) Customers telephone number and addresses are 
stored in databases. When a customer calls, the 
telephone number has to be entered, and 
customer information is displayed on the screen of 
the work station. The operator now enters only 
pickup time and the number of parcels, reducing 
the time of telephone conversation with the 
customer dramatically. 

(2) The system uses the truck database to find the 
truck closest to the pickup location and MCA 
transmits the information to the truck. 

(3) Each truck is equipped with an on boaro 



(1) 



(2) 



(3) 



computer and can receive the pickup orders The 
up-to-date information can be yiewed on a Liquid 
Display Screen (LCD) screen or pr.nted out. 

(4) After pickup the driver enters the conf.rmat.on 
( } which h transmitted the YTC. allowing customer 

parcel tracking and Automatic Vehicle Monrtormg 
(AVM) 

(5) NTT's yellow pages on disks, make it easy to 
maintain updated customer databases eliminating 
entry errors. 



Pickup Order System 



MCA, Radio Srsl<» 
(MOTOROLA) 




53 BBS 

F& & *k 





/ 


I 


/ 



Figure 17 





Figure 18 
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MCA SYSTEM SPECIFICATIONS 
BASE STATION 



(D 
(2) 
(3) 
(4) 
(5) 
(6) 



Motorola (800MHz) MCA SYSTEM 

Fujitsu minicomputer 

Fujitsu FMR personal computers 

Telephone operator Work stations (WS) 16 max. 

UNIX operating system and L*N 

One Fujitsu minicomputer connects with three 

Motorola MCA. 



SYSTEM CAPACITY 



0) 
(2) 
(3). 
(4) 

(5) 

(6) 



1 ,000 Takkyubin trucks 

20,000 customers (Upgrade to 200,000) 

10.000 pickups a day 

Advanced pickup scheduling, 10 per customer, 
1,000 a day. up to 3 months advanced notice 
10.000 district names to simplify address entry 
(Upgrade to 200,000) 

Reports: Operator performance, MCA usage etc. 



YTC added the MCA radio communication 
system and the customer databases to improve pickup 
service. The system combined with our drivers mission 
to serve the customer best, gives YTC a leading edge 
over the competition. 

Base stations are in every major city and business 
areas. Each base station is surrounded by order 
stations (telephone operation centers). These stations 
support over 9.000 Takkyubin trucks. 

2. ROSENBIN CONTROL SYSTEM 

Parcels are collected by Takkyubin trucks and 
transported to the local hub. From there YTC's 



rosenbin trucks transport the parcels to' the destinatio 
hub. The Rosenbin Control System supports, th 
process. 

Every hub has a schedule board similar to th 
departure and arrival boards in airports. This boai 
informs drivers and other employees to facilitate the 
work. 

The number of hubs has steadily increase, 
reaching 64, in August 1992. Rosenbin trucks ha\ 
about 2.000 scheduled routes per day (See figure 5 
During the holiday season additional support routes a< 
added, totaling over 6,000 a day. 

YTC's supervisor used to write standard schedul< 
for' every route. Changes in parcel volume and truck • 
driver availability forced the rewriting of the schedule 
The schedules were then handed to the truck drivers. 

Today the supervisor obtains his schedules from 
PC. He only enters the driver's name and trui 
number. The truck driver enters the number 
containers and additional cargo information. All data 
transferred to update the databases and the Rosent 
Control System's mainframe. 

The above pre-alert information is used by tl 
destination hub to prepare for arriving truck shipment 

Every truck sends a constant identification sign; 
which is received by electronic check points along tl 
roads The truck location is then transmitted to tl 
system. In addition the system allows vol 
communication between trucks and hubs. 



The purpose of this system 
(1) 



(2) 



Advise truck driver of traffic jams, accidents ai 
give alternate routes 

Provide anticipated delivery time for customer 
Give pre-alert information to destination hub 



QD Center 




Radio Base 



But 
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Figure 19 
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Host Ctntilir 

Vthlclt |n(or*ii;«n Ctnltr 



The information provided includes 



ROSENBIN SYSTEM SPECIFICATIONS 



Destination and arrival time 

AVM (Automatic Vehicle Monitoring, Trucks 

location) 

Traffic jams, accidents etc. 

Rosenbin truck schedule status (delays, problems) 

Latest road and weather reports 



(D 

(2) 

(3) 
(4) 
(5) 

. YTC obtained the Ministry of Posts and 
Telecommunication's approval to use two radio 
frequencies throughout Japan, to develop the system. 
Approved frequencies are 382.775 Mhz for truck o 
base communications and 398.775 Mhz. tor base to 
truck communications. In September 199 . a 
Japanese consortium started a project to use a satellite 
for traffic control. The first satellrte based 
communication network will be in operation in spnng 

1993 

YTC has planes to use the satellite network in the 
future. The system will be able give the exact truck 
position anytime, anywhere. We plan to .mplement ^a 
Jew system to use GPS (Global Posrtiomng System) 
which is managed by the Pentagon. 



RADIO BASE 
a MIC 



Rcoote Control lei 




Call Units 



Voice 
File 



CantrolleKCPO) 



(D 
(2) 



(3) 



(4) 
(5) 



(6) 
(7) 



Frequency Band 400 MHz / 
Communication Method 
• Dual frequency 

- Semi-duplex operation 
Transmission Power 

- Base 10W 

- Truck 10W 

1 ,000 trucks capacity 
Transmission activation 

Consecutive for base 

On demand tor truck 
Baud rate is 1.200 bps 
Modulator Method 
MSK 1.200 Hz 2: 100 
Space Frequency band 1.800 ± 100 



3. DIGITAL DRIVING PATTERN MONITORS 

Following police and transportation department's 
guMM. YTC has been using analog 
fecord truck driving speed. ^Zl^ 
replaced with a new generation of digrtal mentors 
This unte with speedometer, odometer, and weight 
sensor input, to track speed, distance .. cargo w»ghL 
This coaches the driver to operate the vehicle 
according to YTC guidelines and improves fleet 
management information. 

The analog monitors were not connected with the 
rest of the ^formation system The 
technology allowed integration of the two systems. 

Advantages of a digital monitors 

(1) All recorded data is feed into the network 

(2) Improved accuracy for driving patterns 

(3) Assists driver 

To be able to start the truck, the driver must insert 
his own IC memory card into the digital unrt The 
recorded information transfers from IC n™«Y* Jj 
POS every 0 5 seconds. This data is feed into the 
NEKO ne^ork YTC benefits from improved safety. 
m or?eSnt scheduling and the capabiWy to analyze 
overall fleet performance. 




" j cj> J information from digital monitors are 



0) 
(2) 
(3) 



Driver name, departure and arrival times 
Fuel and oil consumption 
Operation hours, distance travelled, rest 
speed, length of stops, etc. 



time, 



Figure 20 
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DIGITAL TACHOGRAPHY SAFETY MANAGEMENT 
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Figure 21 

VI. TAKKYUBIN TRUCKS FUTURE 

Door to door parcel service is now a stable 
business monopolized by the big three. But there are 
many improvements needed. A serious problem is 
Japan's acute shortage of human resources. Our 
drivers can deliver an average of a 150 parcels per 
day. YTC has a hard time to hire enough drivers to 
keep up with the constantly increasing parcel volume. 
To ease the driver crunch we reduced their working 
hours, but we still have a shortage. For DTD the driver 
is the core and can not be replaced by any technology. 
Faced with these problems we try increase our 
productivity to perfection. Logistic management 
constantly tries to reduce empty cargo space, 
streamline pickups and reduce redeliveries to a 
minimum. Cost reduction, service improvement, and 



speedier delivery are the driving forces. We ha 
found the almighty strategy, superior inform 
systems to support the drivers are needed. 

Individual hardware and software is getting : 
powerful. However, integration of all our syst 
including communication networks and database 
necessary to meet future demands, i.e. a Infomc 
But we can not afford to forget about the 
important aspect, safety. 

Japan's DTD service has come a long way s 
its start. With over 1.5 billion parcel delivered anm 
we are a strong and respected industry. To pr< 
the best service to our customers, enabled 
success. We will strive to meet our custo; 
demands with total logistic management. 
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The Physical Distribution Information Network 
in the Home-Delivery Business 

111 Takashi Sekita 
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Applications Improvement Dept. 
Yamato Transport Co., Ltd. 

share of Yamato Transport Co. is 40% and it 
is in an oligopolistic situation together with 
•he second ranked Pelican (Nippon Express 
business. It can be said that the .y» «». £ ^ ^ b M%< ^ charaC . 

which reflects the downstream era is a rypical Co* Transpoa Co. is 

^ Also, in the physical distnbuuon bus, M cto«o & 

ness. information is captured at its source n ts d.rect m^ g ^ ^ ^ ^ 

*e procurement. £. and to improve on its thoroughgoing 

consumption stages, and progress is being 1|S 

m ade through improvements in thoroughgo- ^* » * putling vari - 

ing customer services, in quality con.0 1 - ^ ^ h ^ ^.r^vcry Serv- 

improvement of work efficiency, m develop- ous v»n*n ^ ^ ^ 

mem of new systems and in the development ^J™™ homc -delivery serv- 

ofnewbusine.se, In any case, these t^ngs ^-^^ 

donotstopwithattheimprovememoftheef^ ^ IZry home-delivery service, 

ficiency of an individual business, and. as cash onoe 



Recently, information network systems have 
made remarkable progress in the distribution 
business. It can be said that the POS system. 



seen in logistic physical distribution, they ex- 
tend to total sales strategy by the consistent 
utilization of information. This shows the inv 
portance of networks. I hope 1 can help you to 



cool-items home-delivery service, and air- 
port-baggage home-delivery service, in addi- 
Uon to the general-items home-delivery serv- 
ice The service area covers 99.7% of the na- 



portance of networks. I ^ ^ „ $% of ^ population 

understand the relationship between piqued ™* „ ^ delivered on the 



distribution and information by introducing 
our company's "home-deBvery-service infor- 
mation network system" in this arucle. 

1. General Situation of the Home- 
Delivery Service 

Yamato Transport Co. has 40.000 employees. 
1,500 offices and 20.000 vehicles. It handles 
one million home-delivery items a day and 
400 million items a year. Since the total 
number of items handled by the enure home- 



The percentage of items to be delivered on the 
next day is 91% of the total items. 

2. Positioning of the Information Net- 
work System 

A selling point of this home^ielivery service 
is its system. The system can be explained 
using the human body. Offices are developed 
(skeleton) along with the sales strategy 
(brain), loading and unloading (muscle) ac- 
tivities are performed on the basis of the of- 

«»Uc ar\A 



number of items handled by the enure nome- - * ^ ^ ^ 

delivery business is 1 billion items, the market nces. an 



OJl iu4u<ujL»u=fc.uro.rai.uii 



bones is controlled by information (nerves). 
The home-delivery service cannot be carried 
out without an information network system. 

This information can be divided into "up" 
information and "down" information. The 
sources of the "up" information are the items 
to be delivered. The important thing is how 
quickly the item information (slip number, 
customer name, type of item, transport sec- 
tion, fare, etc.) can be obtained. This is the 
origin of the POS concept On the other hand, 
ihe "down" information is feedback of the 
obtained information, and means the uuliza- 
uon of informauon in a way that contributes to 
customer services, quality control and im- 
provement of efficiency. The "down" infer- 
mation does not exist without the "up" infor- 
mation and the "up" informauon does not 
exist on the assumption of the existence of the 
-down" informauon. The thing to connect the 
"up" and "down" information is the database. 
The information network is the general term 
for this. 

3. "Up" Information (Collection of 
Package Information) 



POS (Point Of Sales) in the transport Held 
means the point of receiving packages. Pack- 
age information taken at this point can- con- 
tribute to quality control and customer serv- 
ices. Therefore, our company gives all the 
sales drivers (SDs) a portable terminal so that 
they can input data. Of course, the primary 
role of SDs is the collection and delivery of 
goods, but they contribute to the management 
of the' company by reflecting the viewpoint of 
the customers in their area. This means man- 
agement by all members. SDs are not merely 
doing blind work. They input data when 
packages are taken out for delivery, when the 



delivery is completed (including the bringing 
back of goods), or when abnormal packages 
are found (misdelivery, unknown address, 
breakage, etc.). In such cases, SDs need do 
nothing but scan a slip number (bar code). All 
of the data is transmitted to the host computer 
in Tokyo. 

4. Information Network (NEKO Net) 

The following is the route of information 
transmission. The data collected by the above 
mentioned SDs is stored in their portable ter- 
minals. This portable terminal is called a PP 
(Portable POS) in our company. The terminal 
is connected (jacked in) to a WS (workstation) 
in the office when the SD goes out to make a 
delivery, or when he returns to the office after 
the collection of goods. Then the data is 
transmitted to a small computer (cluster) in- 
stalled at a key base (usually one place in each 
prefecture) that manages the office, through a 
public line. Tne data is automatically trans- 
mined from the cluster to the host computer in 
Tokyo through a leased line (optical cable): 
. that is. all the data is stored in a database of the 
host computer. Then, it is processed accord- 
ing to its purposes, changed into "down" in- 
formation (applicable informauon) and then 
distributed to the necessary locations (See 
Figure 1 & 2). 



5. Database 

* 

The host computer that takes charge of the 
database is located in Kamiuma. Tokyo. It is 
controlled and operated by the Yamato Sys- 
tems Development Co. This is a 100% in- 
vested subsidiary of the Yamato Transport 
Co.. which was created through making the 
computer section of the Yamato Transport 
Co. independent in 1972. Since then, the 
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Yamato Systems Development Co. has under- 
taken not only the important mission of infor- 
mation processing for the Yamato Transport 
Co., it has also responded widely to the de- 
mands of other companies. The data on vari- 
ous goods that is stored in the databases is 
processed according to its use and purpose. 
The company computer is used for on-line op- 
erations from 8:00 am. to 10:30 p.m. and for 
batch processing (fare receivables and related 
billing work, wage calculations, flash reports 
of sales and various statistical operations) 
during the night shift. However, as for the 
'■pursuit of goods, M which is described later, 
batch update is performed at 30-minut£ inter- 
vals in the daytime also for real-time informa- 
tion. By taking the cable fire accident that oc- 
curred in Setagaya in 1984 as a lesson, a 
backup host machine is installed in Osaka. 

6. "Down" Information (Utilization of 
Information) 

Although there are various information us- 
ages, two typical examples will be introduced 
here. 

(1) Package Tracking System 

What is happening to his or her package is the 
customer's greatest concern. Therefore, re- 
plying to this concern is the duty of the trans- 
porter. As described in the section on "up" in- 
formation, package information is stored in 
the host computer, therefore, it can be seen 
immediately when and from where the pack- 
age was sent and what is happening to it now, 
including the delivery process. Although it is 
not easy to search for a certain package from 
a great amount of data, the cunent computer 
can do it without difficulty. 



(2) Checking Service Level (Control or 
the number of transport days) 

What attracts people to the home delivery 
service is that delivery is made on the next 
day. Breaking a promise is an important issue. 
To check this, each delivered item is watched 
with the computer to see where it was sent 
from, where it was transported to and in how 
many days, regardless of whether or not a 
complaint was made. The percentage of unde- 
livered items (the percentage of the number of 
items exceeding the specified number of days 
for transport) is calculated for the territories 
with bad delivery performance. The levels of 
performance are distinguished by color, such 
as red and yellow, as an index to improve the 
quality of transportation. This is outputted 
once a month for an ordinary month and out- 
putted every day in December, which is a busy 
month. 

7. Radio System Using the Computer 

There are two radio systems thai connect ve- 
hicles and offices. One is a collection instruc- 
tion system for collection vehicles and the 
other is an operations control information sys- 
tem for operations vehicles. 

(1) Collection instruction system 

The requests from customers for collection of 
items are made by telephone to an office. The 
reception clerk asks for the customer tele- 
phone number and inputs it into the reception 
machine, then data such as customer name, 
address, and telephone number is displayed 
on the screen. This data is automatically 
transmitted to the appropriate vehicle by wire- 
less and is printed on a primer on the driver's 
seaL Consequently, collection activity can be 
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performed immediately by this system, ena- 
bling just-in-time response to a customers' re- 
quest. 

(2) Operations control information 
system 

This is a tracking system for the operations ve- 
hicles that mainly travel for' long distances at 
night. Check points (offices) are established 
along trunk expressways. A special radio- 
wave network is spread over these areas to 
automatically catch the operations vehicles of 
the company that pass through. This data is 
automatically reported to the host computer 
and the host computer collates the data with 
the schedule. If there is a delayed vehicle, the 
host computer reports this to the destination 
office so that the work setup can be pread- 
justed (See Figure 3). 

8. New Businesses 

The home delivery service network is in- 
volved in the creation of new businesses. 
Recently, direct marketing sales without a 
store, such as direct sales from areas of pro- 
duction and mail order sales are being devel- 
oped, but they cannot be carried out without 
home delivery service as a consumer-direct- 
connection-type system. Therefore, we are 
creating subsidiaries that will provide assis- 
tance services related to customers sales and 
collection of money and information as a 
regular part of business, not as a side business 
to the home delivery service. 

(1) Yamato Collect Service Co., Ltd. 

This is a 100% invested subsidiary of the 
Yamato Transport Co. This company is in 
charge of the cash-on-delivery business of 



home delivery. The payment for goods can be 
collected quickly without errors by append- 
ing the price of the goods to the home delivery 
slip. Although it was performed by the major 
transport companies who called it "cash-on- 
delivery." as it was very troublesome, most of 
the companies tried to avoid it. However, 
with the spreading of the information network 
together with the improvement of home deliv- 
ery service, it can now be performed securely, 
quickly and easily. This business is changing 
with good results. 

(2) Yamato Systems Development Co., 
Ltd. 

This company is a 100% invested subsidiary 
of the Yamato Transport Co.. and manages 
their NEKO system, mentioned above. 
Yamato Systems Development also provides 
computer services to other companies and 
these sales are greater than sales to Yamato 
Transport. This is the first VAN company in 
Japan and it supports various sales systems, 
named Joints, such as telemarketing. POS 
system, collection of payments and agent 
salesman control. The customers need only 
endeavor to use these systems for merchan- 
dise planning and advertisement. The packet 
switching network is overlapped on the 
NEKO Net with access points provided 
throughout the country. This system is sold as 
an assistant (connected with home delivery) 
VAN awaiting customers' use (See Figure 4). 



(3) Book Service Co., Ltd. 

This is a joinl-investmeni company with 
Kurita Bookstore for the sales of publica- 
tions, the procurement of ordered publica- 
tions and their delivery throughout the coun- 
try. As a publications database is available. 



orders made by postcard, telephone, facsimile 
machine and personal computer can be proc- 
essed through their offices all over the coun- 
try, and then the ordered publications are as- 
sembled and delivered. The collecting system 
of Yamato Collect Service is used for the col- 
lection of money. The cost for delivery of a 
standard-sized box is 300 yen throughout the 
country. 



9. Conclusion 

We arc in a global age. Even if it is night 
where you live, somewhere on the earth it is 
day. Japan can keep an all-night vigil. Devel- 
oping an uninterrupted global computer net- 
work will be even more desirable in the fu- 
ture. 
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METHOD AND SYSTEM FOR CONDUCTING 
ELECTRONIC COMMERCE TRANSACTIONS 

Cross-Reference to Related Application 
This application is a continuation-in-part of U.S. Provisional Application No. 
60/054,121, filed July 29, 1997. 

Background 

fifi d of thf invention 

This invention pertains in general to electronic commerce and in particular to a method 
and system for conducting electronic payment transactions via the Internet. 

R ArKfiROlIN " nr THF INVENTION 

Electronic commerce conducted over the Internet has become increasingly important 
over the last decade. Online merchants offer goods and services for sale or rent including 
physical objects such as compact disks, books, and clothing, and intellectual property such as 
streaming music and movies and electronic books. Physical items may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, in contrast, 
may be delivered to the customer by allowing a download via the file transfer protocol 
("FTP"), providing the customer with an access key, establishing a telnet session, or through 
some other form of electronic delivery. 

Typically, these goods and services are displayed on the merchant's web site and a 
prospecuve customer views, selects, and purchases the goods using web browsing software 
such as NETSCAPE NAVIGATOR*. The customer usually pays for a product by establishing 
a secure connection with the merchant's web server and transmitting payment information, 
such as a credit card number, to the merchant. The merchant then uses back-end processing to 
verify the payment information and receive payment. For example, the merchant may use a 
secure telephone line or network link to contact the credit card issuer before accepting the 
customer's order. Eventually, the merchant and credit card issuer settle payment and the 
merchant delivers the product or service to the customer. 

A difficulty with the above-described scenario is that each merchant must implement an 
inventory and payment database and a payment acceptance and verification system. For 
example, the merchant must establish and maintain a database tracking sales, delivery, and 
payment information and product inventories in order to support the electronic commerce 
system. There is significant cost and complexity in maintaining this database, including the 
difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by 
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the scarcity of truly skilled personnel. In addition, the merchant must design web pages to 
securely accept the order and payment information and implement the functionality to verify ' 
the payment. These tasks can be extremely difficult if the merchant accepts payment using 
many different methods, such as credit cards and electronic fund transfers, or accepts payment 
in more than one currency. Moreover, having a large number of separate payment acceptance 
systems on the Internet provides a greater opportunity for fraud and abuse because the flaws of 
each system can be exploited. 

Although Internet-based electronic commerce clearinghouses have been developed to 
handle transactions from many different parties, these clearinghouses do not provide a 
convenient interface to the merchant. In addition, the merchant must still establish the 
payment, verification, and database systems described above. 

Accordingly, there is a need in the art for a method and system for conducting 
electronic commerce on the Internet which reduces the amount of work that must be performed 
by the online merchant. Preferably, the method and system will allow the merchant to easily 
and verifiably perform inventory, sales, and delivery tracking and transparently support 
different types of payments and currencies. 

Summary of the Invention 

The above needs are met by a method and system for conducting electronic commerce 
transactions that allows a merchant to easily sell a mix of physical and intangible items and 
supports sales, inventory, and delivery tracking and a variety of payment systems by having the 
merchant establish an account on a commerce server. The commerce server provides the 
merchant with inventory, accounting, and order management systems. Furthermore, the 
commerce server allows merchants to conduct electronic commerce with other merchants and 
vendors. 

The commerce server includes a web server providing web pages to the merchant. By 
using these web pages, the merchant establishes an account on the commerce server. Then, the 
merchant provides the commerce server with information about an item sold by the merchant, 
such as a plane ticket, clothing, a book, a software product, or playing time with an online 
game. The merchant also provides the commerce server with other attributes of the item from 
which the customer may select, for example, the quantity or duration of an item. In addition, 
the merchant supplies payment processing rules defining the payment options that are 
acceptable to the merchant, such as which currencies and payment systems are allowed and 
when or how often to bill the customer. 



10 



15 



PCT/US98/15884 

WO 99/07121 

The commerce server preferably stores the information received from the merchant in 
an entry of a database. In one embodiment, the database entry categorizes the item as a hard - 
good soft good, or online good depending upon the delivery options available for the item. 
The commerce server, in addition, provides the merchant with a "payment button" includtng a 
5 universal resource locator ("URL") that points to the commerce server and includes 
information allowing the commerce server to identify the database entry with which the 
payment button is associated. The merchant preferably publishes the payment button on the 

merchant's web site. 

The customer selects the payment button when the customer wishes to purchase the 
associated product. In response, the customer's computer is automatically directed to the web 
server managed by the commerce server and provided with the item information entered by the 
merchant. In addition, the customer is presented with the payment options allowed by the 
merchant's payment processing rules. Preferably, the customer then provides the web server 
with the payment information necessary to complete the transaction. 

When the merchant's payment terms specify that payment is required, the commerce 
server preferably identifies the remote payment system selected by the customer and contacts it 
to complete the electronic commerce transaction. Preferably, a module within the commerce 
server converts calls generated by the commerce server into the format used by the selected 
payment system. Likewise, the module converts responses received from the payment system 
20 into the format used by the commerce server. Then, the commerce server notifies the customer 
and the merchant of the result of the electronic commerce transaction and, if appropriate, 
delivers the item using one of the delivery options specified in the database. 

A method of conducting electronic commerce between a remote customer and a remote 
merchant in accordance with the present invention includes receiving information identifying 
25 an item to be purchased by the customer, receiving payment information specifying a payment 
method to be used by the customer to purchase the item, conducting a payment transaction 
with a remote payment system specified by the payment information, and providing the 
customer and the merchant with the result of the payment transaction. 

Similarly, computer program instructions for conducting electronic commerce 
30 transactions in accordance with the present invention include instructions for storing item 
information received from the merchant, instructions for issuing the merchant a reference to 
the stored item information, instructions for receiving an electronic commerce transaction 
identifier from the customer containing the reference to the stored item information issued to 
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the merchant, instructions for accepting payment information from the customer, and 
instructions for conducting the electronic commerce transaction with a remote payment system. 

Brief Description of the Drawings 
5 FIGURE 1 is a high-level block diagram of an electronic commerce system according 

to an embodiment of the present invention; 

FIGURE 2 is a high-level block diagram illustrating functional components of a 
commerce server according to an embodiment of the present invention; 

FIGURE 3 is a high-level block diagram of an entry in a database associated with the 
1 0 commerce server according to an embodiment of the present invention; 

FIGURE 4 is a flow diagram illustrating the interactions between the customer, 
merchant, commerce server, and payment system when completing a payment transaction 
according to an embodiment of the present invention; and 

FIGURE 5 illustrates an exemplary screen display of a web page seeking payment 
15 information from a customer; and 

FIGURE 6 illustrates an exemplary screen display of an order confirmation web page. 

Detailed Description of the Preferred Embodiment 

As used herein, the "Internet" refers to the global network of interconnected computer 
20 systems and the "World Wide Web" ("WWW") refers to the global hypertext system using the 
Internet as its transport mechanism. A "universal resource locator" ("URL") is a reference to a 
piece of information or a software function on a computer connected to the Internet. A "web 
server" is a program that accepts requests for information framed according to the HyperText 
Transport Protocol ("HTTP"). "Web pages" are the information supplied by the web server in 
25 response to the requests. The Common Gateway Interface ("CGI") is the standard that 

describes how the web server accesses external programs, usually called "CGI programs" or 
"CGI scripts," called by a web page. Of course, the present invention is not limited to the 
Internet and may be used with any digital network supporting electronic commerce. In a non- 
Internet-based system, the terms defined above also include the non-Internet-based equivalents 
30 for communicating between the various entities described herein. 

FIG. 1 is a high-level block diagram of an electronic commerce system 100 according 
to an embodiment of the present invention. Illustrated are a customer computer (sometimes 
referred to as "the customer") 1 1 0, a merchant web server (sometimes referred to as "the 
merchant") 112, and a commerce server ("CS") 1 14, all coupled to the Internet 116. In a 
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typical embodiment, the customer computer 1 1 0 is a personal computer having, among other 
things, a processor, memory, storage device, and monitor. The customer computer 1 10 is 
coupled to the Internet 1 1 6 via a network connection 1 1 8. The network connection may be, for 
example, a modem coupled to an analog telephone line, a digital subscriber line, a cable 

5 modem utilizing bandwidth on a cable television coaxial cable, a high speed digital line, or any 
other communications medium. Web browsing software, such as NETSCAPE 
NAVIGATOR*, preferably executes on the client computer and sends data from the client 
computer 1 10 to the merchant web server 1 12 via the network connection 118 and Internet 
1 1 6. In another embodiment, the customer computer 1 10 is a palm-top device or personal 

0 digital system communicating via radio waves with the Internet 1 16 or another electronic 
commerce system. 

The merchant web server 1 12 is preferably similar to the customer computer 1 10 except 
that it is has the processing power and communications 1 16 bandwidth to handle multiple 
simultaneous customer transactions. The merchant 1 12 sells items, such as merchandise, 
15 information, intellectual property, and/or services via a web site hosted on the merchant web 
server 1 12. The merchant's 1 12 web site may, for example, display a catalog of software 
available for purchase, allow the customer 1 1 0 to view flight schedules and purchase a plane 
ticket, or allow the customer 1 10 to play an online game, download a book or music, or access 
a database of information. 
20 As used herein, the terms "customer" and "merchant" depend upon the specific 

transaction being conducted. In a chain of commerce transactions, the "customer" in a first 
transaction may be a "merchant" in a second transaction. For example, the customer 1 10 may 
buy components of a product from several different vendors or merchants 112 using the 
electronic commerce system described herein and then, in turn, sell the combined product via 
25 the customer's own web site and the CS 1 1 4. 

The merchant's web site displays at least one "payment button." A payment button is a 
graphic button, a region of a larger graphic, a text string, or another form of URL link which 
the customer 1 10 may "press" by selecting it with a mouse, physical button, or other input 
device. In another embodiment, the payment button may be utilized on a non-Intemet-based 
30 electronic commerce system. In such an embodiment, the payment button is considered to be 
"pressed" whenever a customer 110 expresses a desire to purchase an item. As described 
below, the payment button is pressed by the customer 1 10 when the customer 1 10 wishes to 
purchase and pay for an item displayed for sale on the merchant's web site. In a preferred 
embodiment, every type of item for sale on the merchant's web site has a separate payment 
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button. When a customer 1 10 wishes to purchase the product, the 1 10 customer presses the 
product's associated payment button. Then, the customer 1 10 is preferably presented with a ' 
menu allowing the customer 1 10 to specify attributes, such as quantity or duration, of the items 
that the customer 1 1 0 wishes to purchase. 
5 In another embodiment, the merchant web site has only one payment button or has only 

one payment button for each class of items for sale. In this embodiment, the customer 1 10 is 
preferably presented with a menu of choices after pressing the payment button. For example, 
the menu of choices may ask the customer 1 10 to identify a specific product or an attribute of a 
product, like color, that the customer 1 1 0 wishes to purchase. 
1 0 Every payment button has an associated URL that points to information in the CS 1 14. 

Preferably, a database key that uniquely identifies the merchant 1 12 and/or item for sale is 
encoded within the URL. When the customer 1 10 presses the payment button, the customer 
1 10 is redirected to a web page provided by the CS 1 14 and specific to the merchant 112 
and/or item. 

1 5 in one embodiment, the CS 1 14 queries the customer for the quantity or duration of the 

item that the customer 1 1 0 wishes to purchase and payment information. The CS 1 14 receives 
the customer's responses and conducts the electronic commerce transaction according to 
payment processing rules and delivery options specified by the merchant 112. The CS 1 14 
records the transaction in its database and notifies the customer and merchant whether the 

20 transaction was successful. Accordingly, the merchant 1 12 is relieved of the responsibility of 
conducting the electronic commerce transaction with the customer 110. 

FIG. 2 is a high-level block diagram illustrating functional components of the CS 114 
and also illustrating a remote payment system 222 and a remote merchant 223 according to a 
preferred embodiment of the present invention. The CS 1 14 is preferably similar to the 

25 customer 1 10 and merchant 1 12 computers, except that the CS 1 14 has enough processing 
power and Internet 1 16 bandwidth to support many simultaneous payment button transactions 
as described herein. The functionality of the CS 1 14 described herein may be performed by 
hardware or software modules within the CS 1 14. In one embodiment of the present invention, 
the functionality of the CS 1 14 is provided by software applications executing on INTEL x86- 

30 or SUN MICROSYSTEMS SPARC-compatible hardware under control of MICROSOFT 
WINDOWS NT or a derivative of the UNIX operating system, such as SOLARIS 2.5.1. In 
another embodiment of the present invention, the functionality of the CS 1 14 is provided by a 
distributed computing system as described below. 

6 
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The remote payment system 222 is preferably a third-party payment gateway or system. 
The gateway or system is preferably connected to a financial transaction network, which, in - 
turn, typically links to computers at banks and other financial institutions for approval and 
settlement of electronic commerce transactions. Typical gateways or systems may include 
5 CYBERCASH, e-CASH, MONDEX, or SET. While only one payment system 222 is 
illustrated in FIG. 2, the CS 1 14 may be in communication with many different remote 
payment systems 222, either through a secure link on the Internet 1 16 or a dedicated secure 
link. Each payment system has an applications programming interface ("API"). By using the 
API, the CS 1 14 communicates with the payment system 222 and performs secure and 
10 verifiable payment transactions. 

The remote merchant 223 is preferably a merchant selling items via a web site as 
described above. The remote merchant 223 may have an account on the CS 1 14 or the 
merchant 223 may have an interface for selling items similar to the remote payment system 
222. In general, the remote merchant 223 is included in FIG. 2 to illustrate that the customer's 
15 110 electronic commerce transaction performed by the CS 1 14 may contact a remote payment 
system 222 and/or a remote merchant 223. 

The CS 1 14 includes a payment button transaction engine 210 which is coupled to a 
database 212 and a web server 214. A firewall 216 preferably sits between the web server 216 
and the transaction engine 210. While these functional components are illustrated in FIG. 2 as 
20 discrete entities, the CS 1 1 4 may be executed on a distributed computer system having a 
plurality of engines, databases, and web servers working together the perform the functions 
described herein. For example, one embodiment of the CS 1 14 uses multiple transaction 
engines 210 and web servers 214 and a single distributed database 212, thereby providing 
scalability to the CS 1 14. The number of web servers 214 and transaction engines 210 depends 
25 on the actual system load and the desire to achieve better performance through balancing the 
transaction load across the system. 

The payment button transaction engine 210 includes a rules module 218 that controls 
the interactions and flows of information necessary to complete a payment transaction. In 
addition, the transaction engine 210 preferably includes a Payment Application Programming 
30 Interface ("PAPI") module 220 enabling communication between the CS 1 1 4 and the remote 
payment systems 222 and merchants 223. The PAPI module 220 abstracts the different APIs 
of each payment system 222 and merchant 223 into a single, higher level, PAPI that can 
interface with each of the payment systems 222 and merchants 223. The transaction engine 
210 performs payment transactions with a payment system 222 or merchant 223 by making 
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calls to the PAPI. The PAPI abstraction module 220 translates these calls into the specific API 
of the payment system 222 or merchant 223 being used for that transaction. The PAPI 
abstraction module 220 also translates data received from the payment system 222 or merchant 
223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction 
5 module 220 allows support for new payment systems 222 and merchants 223 to be added to the 
CS 1 14 by merely creating a new PAPI to payment system or merchant API mapping in the 
PAPI abstraction module 220. 

The payment button store module ("PB store") 224, in combination with the web server 
214, allows a merchant 1 12 to obtain a payment button. The web server 214 is preferably an 

1 0 industry standard web server such as the NETSCAPE ENTERPRISE SERVER or the 

APACHE web server. The web server 214 provides secure communication with the customer 
1 1 0 and preferably uses industry standard technologies including HyperText Markup Language 
("HTML"), and HTTP to deliver information to the customer 110. In addition, the web server 
preferably uses industry standard encryption techniques, including secure HTTP ("S-HTTP") 

15 and the secure sockets layer ("SSL"), to ensure that communications with the customer 1 10 are 
private. The firewall 216 allows only authorized communications between the web server 214 
and the transaction engine 210 and ensures that a malicious user cannot access or corrupt the 
transaction engine 210. 

The PB store 224 allows the merchant to purchase payment buttons and add product 

20 descriptions, merchant configurations, and other information to the database 212. In a 

preferred embodiment of the present invention, the merchant 1 12 accesses the PB store through 
a web site on the web server 214. The PB store module 224 captures the merchant 1 12 actions 
on the web server 214 and creates the appropriate entries in the database 212. 

In one embodiment of the present invention, the PB store web site describes the 

25 payment button mechanism, the services offered by the payment button vendor, and the costs 
of the services. In addition, the web site preferably has a merchant registration form 226 for 
registering new merchants, a merchant renewal form 228 for renewing merchant registrations, 
and a payment button generation form 230 for issuing payment buttons to registered 
merchants. The forms preferably include CGI programs for performing the functionality 

30 described herein. 

The merchant registration form 226 allows the merchant 1 12 to input information 
identifying the merchant 112 and includes a payment button with which the merchant 1 12 can 
pay a registration fee. After the fee payment is verified, the merchant 1 12 is preferably issued 
a login/password pair and an account with the CS 1 14 through which the merchant 1 12 can 
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access the payment button generation form and maintain the merchant's account. Similarly, 
the merchant renewal form 228 preferably includes a payment button with which the merchant 
112 can pay a renewal fee. 

The payment button generation form 230 allows the merchant 1 12 to enter item 

5 description data, such as item names and descriptions, prices, types, and delivery options, and 
payment processing rules, such as supported credit cards, payment systems, and currencies. In 
addition, the payment processing rules may rank the payment systems in order of preference, 
describe when payment is required (e.g., the merchant may require billing after 90 days), 
and/or describe the quantity or duration of an item available for a certain price. In one 

1 0 embodiment of the present invention, the merchant 1 1 2 enters the item description data and 
payment processing rules by uploading a file to web site having the information in a 
standardized format. 

When entry of this data is completed, the payment button generation form 230 sends 
the data to the transaction engine 210, which stores the information in the database 212 at a 

1 5 location specified by a key. The transaction engine 2 1 0 passes the key back to the PB store 
web site, which provides the merchant with a payment button download page displaying the 
results of the payment button generation transaction. If the transaction was successful, the 
payment button download page includes the payment button issued to the merchant 1 12. The 
payment button has an associated URL that specifies the key. Accordingly, little or no 

20 engineering effort is required to maintain each merchant configuration on the CS 1 14. 

In one embodiment of the present invention, there are multiple PB store web sites 
communicating with the database 212 through the transaction engine 210. When a payment 
button is created, the transaction engine 210 creates a field in the database 212 entry specifying 
the PB store that generated the payment button. Accordingly, payment buttons may be 

25 "branded" among different payment button vendors. 

The database 212 is preferably a robust relational database. A preferred embodiment of 
the present invention uses the ORACLE 7 database to implement the functionality described 
herein. The database 212 stores item descriptions, payment processing rules, and other 
information necessary to complete a payment transaction on behalf of a merchant 1 12. This 

30 merchant information is preferably accessed in the database by using a key assigned to each 
merchant 1 12 and/or item for sale. The database 212 is also used as a repository of transaction 
information including authorization logs, payment status and completion records, and other 
information required by the merchant 1 12 and the CS 1 14. 
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FIG. 3 is a high-level block diagram of functional components within the database 212. 
Illustrated therein are a database entry 300 including a primary entry 310 linked to at least one 
of three types of item entries 312, 314, 316. The primary entry 310 is the entry identified by 
the key provided to the merchant 1 12. Accordingly, the primary entry 310 is typically 
5 accessed either when the merchant 1 12 provides the key while using the PB store web site or 
when the customer 1 1 0 uses the URL provided by a payment button to purchase the item 
identified in the database entry 310. 

The primary entry 310 contains a field 318 storing the payment processing rules for the 
item as specified by the merchant 1 1 2 through the PB store. The primary entry 3 1 0 also 
1 0 contains a field 320 holding item type information as specified by the merchant 1 12. The item - 
type information preferably describes the item attributes input by the merchant 1 12. In 
addition, the item type information field 320 preferably contains at least one link to another 
database entry 312, 314, 316 describing delivery options for the item. 

The available delivery options for an item depend upon the type of item. FIG. 3 
1 5 illustrates three database entries 3 1 2, 3 1 4, 3 1 6 describing delivery options for hard, soft, and 
online items. However, an embodiment of the present invention may have many different 
types of items and corresponding delivery options. A hard item is typically a manufactured 
physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 
holding delivery options 322 may list various shipping methods and companies available for 
20 delivering the hard item to the customer 110. 

A soft item, in contrast, is typically intangible intellectual property such as music, 
electronic books ; or software. For example, the soft item may be a streaming music file that 
can be played by the customer 110. Accordingly, the entry 314 holding delivery options 324 
may list a URL or electronic key that can be provided to the customer to effectuate the 
25 purchase. For example, the options 324 may provide instructions for initiating an FTP session 
to download the purchased soft item to the customer's 1 10 computer system. 

An online item is typically access to an online service or other software executing 
remotely from the customer 110. For example, the online item may be access to an electronic 
database of information or an online game. Accordingly, the entry 3 1 6 holding delivery 
30 options 326 preferably includes instructions for allowing the customer 1 10 to access the online 
item. For example, the options 326 may provide instructions for initiating a telnet session with 
an electronic database for a limited duration of time. 

FIG. 4 is a flow diagram illustrating the interactions between the customer 110, 
merchant 1 12, CS 1 14, database 212 and a payment system 222 when completing a payment 

10 



WO 99/07121 PCT/US98/15884 

transaction according to a preferred embodiment of the present invention. In the flow diagram, 
time flows from the top of the diagram to the bottom and horizontal lines represent 
communications between the various entities. FIG. 4 illustrates only major interactions 
between the entities and does not represent every interaction. In addition, FIG. 4 illustrates a 
simple case of the present invention wherein the merchant's 1 12 payment processing rules 
specify that the payment transaction should be processed at the time the customer's 1 10 order 
is received. 

Initially, the customer 1 10 is browsing the merchant's web site and decides to purchase 
an item by pressing 410 the associated payment button. In response to the press, the 
merchant's web server 112 redirects 412 the customer's browser to the location on the CS 1 14 
specified by the URL associated with the payment button. The customer's browser fetches 414 
the referenced page from the CS 1 14. 

The CS 114 parses the URL received from the customer 1 10 for the database 212 key 
corresponding to the item that the customer 1 10 wishes to purchase. Using this key, the CS 
114 accesses 41 6 the database 212 and dynamically generates a web page indicating the 
attributes and payment options available for the item as defined by the merchant 1 12. In 
addition, the CS 1 14 preferably determines the language utilized by the customer 1 10 and 
currencies supported by the merchant 1 1 2 and modifies the web page accordingly. This 
generated web page is sent 418 to the customer 110. FIG. 5 illustrates an exemplary screen 
display 500 of the web page seeking payment information from the customer 110. 

The customer selects the desired item attributes and payment service, enters any 
necessary payment information, such as a credit card or account number, and transmits 420 
these data to the CS 114. TheCS 1 14 stores 422 the received data in the database 212 and 
contacts the selected payment system 222. As described above, the CS 1 14 preferably uses the 
PAPI module 220 to translate transaction calls made by the transaction engine 210 into the API 
of the selected payment system 222. The CS 1 14 preferably stores 426 records of all 
communications with the payment system 222, customer 1 10, and merchant 1 12 in the 
database 212. Therefore, the database 212 can be used to reconstruct transaction histories in 
order to provide error tracking and accounting services. If the payment system 222 rejects the 
transaction, the CS 1 14 publishes a web page to the customer indicating this result and 
presenting alternative payment methods, if any (this interaction is not shown in FIG. 4). 

If the payment system 222 approves the transaction, the CS dynamically generates a 
web page containing payment status information and publishes 428 this information to the 
customer 1 1 0. This page preferably contains a receipt or confirmation number generated by 
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the CS 114. In a preferred embodiment of the present invention, the confirmation number is a 
unique number encoding transaction, session, and merchant identifications and a time and date 
stamp. This confirmation number is preferably a key to a database entry holding the 
transaction information and can be used later by the merchant 1 12 and customer 1 10 to confirm 
5 payment, to query the CS 1 14 for payment status information, and to use the CS 1 14 to query 
the payment system for account status information; The web page also preferably contains any 
other information required by the merchant 1 12 and a link to a confirmation page on the 
merchant's web site 1 12. FIG. 6 illustrates an exemplary screen display 600 of an order 
confirmation web page. 

1 0 The CS 1 1 4 also notifies 428 the merchant 1 1 2 that payment was accepted and provides - 

the same receipt or confirmation number as was provided to the customer 1 10. In one 
embodiment, this notification is performed via a secure electronic mail message. Accordingly, 
both the customer 1 1 0 and merchant 1 1 2 are notified that the purchase was made. 

Finally, the customer 110 fetches 430 the confirmation web page on the merchant's 

15 web site. Preferably, this web page provides the customer 1 10 with additional information 
about the purchase or any other information which the merchant 1 1 2 desires to provide. 

In summary, the present invention is a system, method, and computer program 
instructions for conducting electronic commerce transactions via the Internet or any electronic 
communication system. The merchant 1 12 opens an account on the CS 1 14 and supplies 

20 information about items sold by the merchant 112. The CS 1 14 stores this information in a 
database 212 entry and issues the merchant 112 a URL containing the key to database entry. 
The merchant 1 1 2 supplies this URL to customers wishing to purchase an item, causing a 
customer 1 10 to be connected to the CS 1 14. The CS 1 14 collects payment information from 
the customer 1 10, conducts the electronic commerce transaction with a remote payment system 

25 222, and notifies the customer 1 10 and merchant 112 of the result. 
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Claims 

I claim: 

1 A computer system for supporting electronic commerce transactions between a 
customer and a remote merchant, the computer system comprising: 

a database having an entry including merchant information identifying an item 

offered for sale by the remote merchant; and 
a transaction engine in communication with the database and a remote payment 
system for performing an electronic commerce transaction, the transaction 
engine comprising: 

a first module for receiving an electronic commerce transaction identifier 

from the customer, the electronic commerce transaction identifier 

specifying the entry in the database; 
a second module for accepting payment information from the customer, the 

payment information identifying the remote payment system; and 
a third module for performing the electronic commerce transaction with the 

remote payment system using the payment information received 

from the customer. 

2. The computer system of claim 1 , wherein the transaction engine further 
comprises: 

a fourth module for notifying the remote merchant and the customer of a result of 
the electronic commerce transaction. 

3. The computer system of claim 1 , further comprising: 

a web server in communication with the transaction engine for communicating with 

the remote merchant and customer; and 
a firewall between the web server and the transaction engine for securing 

communications between the web server and the transaction engine. 

4. The computer system of claim 3, wherein the transaction engine further 
comprises: 

a fifth module for dynamically generating a web page from the entry in the database 
and providing the web page to the customer via the web server, the web 
page providing information about the item offered for sale by the remote 
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merchant and facilitating collection of the payment information from the 
customer. 

5. The computer system of claim 3, wherein the computer system further 
comprises: 

a sixth module for accepting the merchant information identifying the item offered 
for sale by the remote merchant via the web server, creating the database 
entry for holding the merchant information, and providing the remote 
merchant with a reference to the database entry. 

6. The computer system of claim 1 , wherein the electronic commerce transaction 
identifier is a URL identifying the computer system and including a key to the entry in the 
database. 

7. The computer system of claim 1, wherein the database further comprises: 

an entry specifying payment processing rules defined by the remote merchant; and 
an entry specifying delivery options for the item offered for sale by the remote 
merchant. 

8. The computer system of claim 1 , wherein there are a plurality of available 
remote payment systems and wherein the second module for accepting payment information 
from the customer accepts payment information identifying one of the available remote 
payment systems. 

9. The computer system of claim 1 , wherein the transaction engine is executed by 
a plurality of distributed computer systems. 

10. A method of conducting electronic commerce between a remote customer and a 
remote merchant, the method comprising the steps of: 

receiving information identifying an item to be purchased by the remote customer; 
receiving payment information specifying a payment method to be used by the 

remote customer to purchase the item; 
conducting a payment transaction with a remote payment system specified by the 

payment information; and 
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providing the remote customer and the remote merchant with a result of the 
payment transaction. 

1 1 . The method of claim 10, further comprising the steps of: 

receiving information about the item to be purchased from the remote merchant; 
5 storing the information about the item to be purchased at a specified location; and 

providing the remote merchant with a reference to the specified location. 

12. The method of claim 1 1 , wherein the remote merchant provides the reference to 
the specified location to the remote customer responsive to the remote customer desiring to 
purchase the item. 

10 13. The method of claim 10, further comprising the step of: 

providing the remote customer with a list of item attributes from which the 
customer can select. 

14. The method of claim 10, wherein the step of receiving information identifying 
the item to be purchased by the remote customer comprises the steps of: 

1 5 receiving payment processing rules specifying payment options available for 

purchasing the item; and 
receiving delivery options for the item. 

1 5. A computer-readable medium having computer instructions encoded thereon for 
conducting electronic commerce transactions between a remote merchant and a remote 

20 customer, the computer instructions comprising: 

instructions for storing item information received from the remote merchant; 
instructions for issuing the remote merchant a reference to the stored item 
information; 

instructions for receiving an electronic commerce transaction identifier from the 
25 remote customer containing the reference to the stored item information 

issued to the remote merchant; 
instructions for accepting payment information from the remote customer, the 

payment information identifying a remote payment system; and 
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instructions for conducting the electronic commerce transaction with the remote 
payment system using the payment information received from the remote ' 
customer. 

16. The computer-readable medium of claim 15, wherein the instructions further 
comprise: 

instructions for notifying the remote merchant and the remote customer of a result 
of the electronic commerce transaction. 

1 7. The computer-readable medium of claim 1 5, wherein the instructions for storing 
item information received from the remote merchant comprise: 

instructions for receiving payment processing rules from the remote merchant 

specifying payment options for the electronic commerce transaction; and 

instructions for receiving delivery rules from the remote merchant specifying 
delivery options for the electronic commerce transaction. 
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METHOD AND SYSTEM FOR CONDUCTING 
ELECTRONIC COMMERCE TRANSACTIONS 

Cross-Reference to Related Application 
This application is a continuation-in-part of U.S. Provisional Application No. 
60/054,121, filed July 29, 1997. 

Background 

Fifi n of thf Invention 

This invention pertains in general to electronic commerce and in particular to a method 
and system for conducting electronic payment transactions via the Internet. 

RACKGROt>""> OF THE INVENTION 

Electronic commerce conducted over the Internet has become increasingly important 
over the last decade. Online merchants offer goods and services for sale or rent including 
physical objects such as compact disks, books, and clothing, and intellectual property such as 
streaming music and movies and electronic books. Physical items may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, in contrast, 
may be delivered to the customer by allowing a download via the file transfer protocol 
("FTP"), providing the customer with an access key, establishing a telnet session, or through 
some other form of electronic delivery. 

Typically, these goods and services are displayed on the merchant's web site and a 
prospective customer views, selects, and purchases the goods using web browsing software 
such as NETSCAPE NAVIGATOR^. The customer usually pays for a product by establishing 
a secure connection with the merchant's web server and transmitting payment information, 
such as a credit card number, to the merchant. The merchant then uses back-end processing to 
verify the payment information and receive payment. For example, the merchant may use a 
secure telephone line or network link to contact the credit card issuer before accepting the 
customer's order. Eventually, the merchant and credit card issuer settle payment and the 
merchant delivers the product or service to the customer. 

A difficulty with the above-described scenario is that each merchant must implement an 
inventory and payment database and a payment acceptance and verification system. For 
example, the merchant must establish and maintain a database tracking sales, delivery, and 
payment information and product inventories in order to support the electronic commerce 
system. There is significant cost and complexity in maintaining this database, including the 
difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by 
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the scarcity of truly skilled personnel. In addition, the merchant must design web pages to 
securely accept the order and payment information and implement the functionality to verify 
the payment. These tasks can be extremely difficult if the merchant accepts payment using 
many different methods, such as credit cards and electronic fund transfers, or accepts payment 
5 in more than one currency. Moreover, having a large number of separate payment acceptance 
systems on the Internet provides a greater opportunity for fraud and abuse because the flaws of 
each system can be exploited. 

Although Internet-based electronic commerce clearinghouses have been developed to 
handle transactions from many different parties, these clearinghouses do not provide a 

1 0 convenient interface to the merchant. In addition, the merchant must still establish the 
payment, verification, and database systems described above. 

Accordingly, there is a need in the art for a method and system for conducting 
electronic commerce on the Internet which reduces the amount of work that must be performed 
by the online merchant. Preferably, the method and system will allow the merchant to easily 

1 5 and verifiably perform inventory, sales, and delivery tracking and transparently support 
different types of payments and currencies. 

Summary of the Invention 

The above needs are met by a method and system for conducting electronic commerce 
20 transactions that allows a merchant to easily sell a mix of physical and intangible items and 

supports sales, inventory, and delivery tracking and a variety of payment systems by having the 
merchant establish an account on a commerce server. The commerce server provides the 
merchant with inventory, accounting, and order management systems. Furthermore, the 
commerce server allows merchants to conduct electronic commerce with other merchants and 
25 vendors. 

The commerce server includes a web server providing web pages to the merchant. By 
using these web pages, the merchant establishes an account on the commerce server. Then, the 
merchant provides the commerce server with information about an item sold by the merchant, 
such as a plane ticket, clothing, a book, a software product, or playing time with an online 
30 game. The merchant also provides the commerce server with other attributes of the item from 
which the customer may select, for example, the quantity or duration of an item. In addition, 
the merchant supplies payment processing rules defining the payment options that are 
acceptable to the merchant, such as which currencies and payment systems are allowed and 
when or how often to bill the customer. 
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The commerce server preferably stores the information received from the merchant in 
an entry of a database. In one embodiment, the database entry categorizes the item as a hard 
good, soft good, or online good depending upon the delivery options available for the item. 
The commerce server, in addition, provides the merchant with a "payment button" including a 
5 universal resource locator ("URL") that points to the commerce server and includes 
information allowing the commerce server to identify the database entry with which the 
payment button is associated. The merchant preferably publishes the payment button on the 
merchant's web site. 

The customer selects the payment button when the customer wishes to purchase the 
1 0 associated product. In response, the customer's computer is automatically directed to the web 
server managed by the commerce server and provided with the item information entered by the 
merchant. In addition, the customer is presented with the payment options allowed by the 
merchant's payment processing rules. Preferably, the customer then provides the web server 
with the payment information necessary to complete the transaction. 
1 5 When the merchant's payment terms specify that payment is required, the commerce 

server preferably identifies the remote payment system selected by the customer and contacts it 
to complete the electronic commerce transaction. Preferably, a module within the commerce 
server converts calls generated by the commerce server into the format used by the selected 
payment system. Likewise, the module converts responses received from the payment system 
20 into the format used by the commerce server. Then, the commerce server notifies the customer 
and the merchant of the result of the electronic commerce transaction and, if appropriate, 
delivers the item using one of the delivery options specified in the database. 

A method of conducting electronic commerce between a remote customer and a remote 
merchant in accordance with the present invention includes receiving information identifying 
25 an item to be purchased by the customer, receiving payment information specifying a payment 
method to be used by the customer to purchase the item, conducting a payment transaction 
with a remote payment system specified by the payment information, and providing the 
customer and the merchant with the result of the payment transaction. 

Similarly, computer program instructions for conducting electronic commerce 
30 transactions in accordance with the present invention include instructions for storing item 
information received from the merchant, instructions for issuing the merchant a reference to 
the stored item information, instructions for receiving an electronic commerce transaction 
identifier from the customer containing the reference to the stored item information issued to 
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the merchant, instructions for accepting payment information from the customer, and 
instructions for conducting the electronic commerce transaction with a remote payment system. 

Brief Description of the Drawings 
5 FIGURE 1 is a high-level block diagram of an electronic commerce system according 

to an embodiment of the present invention; 

FIGURE 2 is a high-level block diagram illustrating functional components of a 
commerce server according to an embodiment of the present invention; 

FIGURE 3 is a high-level block diagram of an entry in a database associated with the 
10 commerce server according to an embodiment of the present invention; 

FIGURE 4 is a flow diagram illustrating the interactions between the customer, 
merchant, commerce server, and payment system when completing a payment transaction 
according to an embodiment of the present invention; and 

FIGURE 5 illustrates an exemplary screen display of a web page seeking payment 
15 information from a customer; and 

FIGURE 6 illustrates an exemplary screen display of an order confirmation web page. 

Detailed Description of the Preferred Embodiment 

As used herein, the "Internet" refers to the global network of interconnected computer 
20 systems and the "World Wide Web" ("WWW") refers to the global hypertext system using the 
. Internet as its transport mechanism. A "universal resource locator" ("URL") is a reference to a 
piece of information or a software function on a computer connected to the Internet. A "web 
server" is a program that accepts requests for information framed according to the HyperText 
Transport Protocol ("HTTP"). "Web pages" are the information supplied by the web server in 
25 response to the requests. The Common Gateway Interface ("CGI") is the standard that 

describes how the web server accesses external programs, usually called "CGI programs" or 
"CGI scripts " called by a web page. Of course, the present invention is not limited to the 
Internet and may be used with any digital network supporting electronic commerce. In a non- 
Internet-based system, the terms defined above also include the non-Internet-based equivalents 
30 for communicating between the various entities described herein. 

FIG. 1 is a high-level block diagram of an electronic commerce system 100 according 
to an embodiment of the present invention. Illustrated are a customer computer (sometimes 
referred to as "the customer") 1 10, a merchant web server (sometimes referred to as "the 
merchant") 1 12, and a commerce server ("CS") 114, all coupled to the Internet 116. In a 
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typical embodiment, the customer computer 1 10 is a personal computer having, among other 
things, a processor, memory, storage device, and monitor. The customer computer 1 10 is 
coupled to the Internet 1 16 via a network connection 118. The network connection may be, for 
example, a modem coupled to an analog telephone line, a digital subscriber line, a cable 

5 modem utilizing bandwidth on a cable television coaxial cable, a high speed digital line, or any 
other communications medium. Web browsing software, such as NETSCAPE 
NAVIGATOR®, preferably executes on the client computer and sends data from the client 
computer 1 1 0 to the merchant web server 1 1 2 via the network connection 1 1 8 and Internet 
1 1 6. In another embodiment, the customer computer 1 10 is a palm-top device or personal 

1 0 digital system communicating via radio waves with the Internet 1 1 6 or another electronic 
commerce system. 

The merchant web server 1 12 is preferably similar to the customer computer 1 10 except 
that it is has the processing power and communications 1 16 bandwidth to handle multiple 
simultaneous customer transactions. The merchant 1 12 sells items, such as merchandise, 
1 5 information, intellectual property, and/or services via a web site hosted on the merchant web 
server 1 12. The merchant's 1 12 web site may, for example, display a catalog of software 
available for purchase, allow the customer 1 10 to view flight schedules and purchase a plane 
ticket, or allow the customer 1 10 to play an online game, download a book or music, or access 
a database of information. 
20 As used herein, the terms "customer" and "merchant" depend upon the specific 

transaction being conducted. In a chain of commerce transactions, the "customer" in a first 
transaction may be a "merchant" in a second transaction. For example, the customer 110 may 
buy components of a product from several different vendors or merchants 112 using the 
electronic commerce system described herein and then, in turn, sell the combined product via 
25 the customer's own web site and the CS 114. 

The merchant's web site displays at least one "payment button." A payment button is a 
graphic button, a region of a larger graphic, a text string, or another form of URL link which 
the customer 1 10 may "press" by selecting it with a mouse, physical button, or other input 
device. In another embodiment, the payment button may be utilized on a non-Internet-based 
30 electronic commerce system. In such an embodiment, the payment button is considered to be 
"pressed" whenever a customer 110 expresses a desire to purchase an item. As described 
below, the payment button is pressed by the customer 1 10 when the customer 1 10 wishes to 
purchase and pay for an item displayed for sale on the merchant's web site. In a preferred 
embodiment, every type of item for sale on the merchant's web site has a separate payment 
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button. When a customer 1 10 wishes to purchase the product, the 1 10 customer presses the 
product's associated payment button. Then, the customer 1 10 is preferably presented with a 
menu allowing the customer 1 10 to specify attributes, such as quantity or duration, of the items 
that the customer 110 wishes to purchase. - 
5 In another embodiment, the merchant web site has only one payment button or has only 

one payment button for each class of items for sale. In this embodiment, the customer 1 10 is 
preferably presented with a menu of choices after pressing the payment button. For example, 
the menu of choices may ask the customer 1 10 to identify a specific product or an attribute of a 
product, like color, that the customer 1 10 wishes to purchase. 
10 Every, payment button has an associated URL that points to information in the CS 1 14. . 

Preferably, a database key that uniquely identifies the merchant 112 and/or item for sale is 
encoded within the URL. When the customer 110 presses the payment button, the customer 
1 10 is redirected to a web page provided by the CS 1 14 and specific to the merchant 1 12 
and/or item. 

15 In one embodiment, the CS 1 14 queries the customer for the quantity or duration of the 

item that the customer 110 wishes to purchase and payment information. The CS 1 14 receives 
the customer's responses and conducts the electronic commerce transaction according to 
payment processing rules and delivery options specified by the merchant 112. The CS 114 
records the transaction in its database and notifies the customer and merchant whether the 

20 transaction was successful. Accordingly, the merchant 1 12 is relieved of the responsibility of 
conducting the electronic commerce transaction with the customer 110. 

FIG. 2 is a high-level block diagram illustrating functional components of the CS 1 14 
and also illustrating a remote payment system 222 and a remote merchant 223 according to a 
preferred embodiment of the present invention. The CS 1 14 is preferably similar to the 

25 customer 1 10 and merchant 1 12 computers, except that the CS 1 14 has enough processing 
power and Internet 1 1 6 bandwidth to support many simultaneous payment button transactions 
as described herein. The functionality of the CS 1 14 described herein may be performed by 
hardware or software modules within the CS 114. In one embodiment of the present invention, 
the functionality of the CS 1 14 is provided by software applications executing on INTEL x86- 

30 or SUN MICROSYSTEMS SP ARC-compatible hardware under control of MICROSOFT 
WINDOWS NT or a derivative of the UNIX operating system, such as SOLARIS 2.5.1 . In 
another embodiment of the present invention, the functionality of the CS 1 14 is provided by a 
distributed computing system as described below. 
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The remote payment system 222 is preferably a third-party payment gateway or system. 
The gateway or system is preferably connected to a financial transaction network, which, in 
turn, typically links to computers at banks and other financial institutions for approval and 
settlement of electronic commerce transactions. Typical gateways or systems may include 
CYBERCASH, e-CASH, MONDEX, or SET. While only one payment system 222 is 
illustrated in FIG. 2, the CS 1 14 may be in communication with many different remote 
payment systems 222, either through a secure link on the Internet 1 16 or a dedicated secure 
link. Each payment system has an applications programming interface ("API")- By using the 
API, the CS 1 1 4 communicates with the payment system 222 and performs secure and 
verifiable payment transactions. 

The remote merchant 223 is preferably a merchant selling items via a web site as 
described above. The remote merchant 223 may have an account on the CS 1 14 or the 
merchant 223 may have an interface for selling items similar to the remote payment system 
222. In general, the remote merchant 223 is included in FIG. 2 to illustrate that the customer's 
1 10 electronic commerce transaction performed by the CS 1 14 may contact a remote payment 
system 222 and/or a remote merchant 223. 

The CS 1 14 includes a payment button transaction engine 210 which is coupled to a 
database 212 and a web server 214. A firewall 216 preferably sits between the web server 216 
and the transaction engine 210. While these functional components are illustrated in FIG. 2 as 
discrete entities, the CS 1 14 may be executed on a distributed computer system having a 
plurality of engines, databases, and web servers working together the perform the functions 
described herein. For example, one embodiment of the CS 114 uses multiple transaction 
engines 210 and web servers 214 and a single distributed database 212, thereby providing 
scalability to the CS 1 14. The number of web servers 214 and transaction engines 210 depends 
on the actual system load and the desire to achieve better performance through balancing the 
transaction load across the system. 

The payment button transaction engine 210 includes a rules module 218 that controls 
the interactions and flows of information necessary to complete a payment transaction. In 
addition, the transaction engine 210 preferably includes a Payment Application Programming 
Interface ("PAPI") module 220 enabling communication between the CS 1 14 and the remote 
payment systems 222 and merchants 223. The PAPI module 220 abstracts the different APIs 
of each payment system 222 and merchant 223 into a single, higher level, PAPI that can 
interface with each of the payment systems 222 and merchants 223. The transaction engine 
210 performs payment transactions with a payment system 222 or merchant 223 by making 
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calls to the PAPI. The PAPI abstraction module 220 translates these calls into the specific API 
of the payment system 222 or merchant 223 being used for that transaction. The PAPI 
abstraction module 220 also translates data received from the payment system 222 or merchant 
223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction 
5 module 220 allows support for new payment systems 222 and merchants 223 to be added to the 
CS 1 14 by merely creating a new PAPI to payment system or merchant API mapping in the 
PAPI abstraction module 220. 

The payment button store module ("PB store") 224, in combination with the web server 
214, allows a merchant 1 12 to obtain a payment button. The web server 214 is preferably an 

1 0 industry standard web server such as the NETSCAPE ENTERPRISE SERVER or the 

APACHE web server. The web server 214 provides secure communication with the customer 
1 10 and preferably uses industry standard technologies including HyperText Markup Language 
("HTML"), and HTTP to deliver information to the customer 110. In addition, the web server 
preferably uses industry standard encryption techniques, including secure HTTP ("S-HTTP") 

15 and the secure sockets layer ("SSL"), to ensure that communications with the customer 1 10 are 
private. The firewall 216 allows only authorized communications between the web server 214 
and the transaction engine 210 and ensures that a malicious user cannot access or corrupt the 
transaction engine 210. 

The PB store 224 allows the merchant to purchase payment buttons and add product 

20 descriptions, merchant configurations, and other information to the database 212. In a 

preferred embodiment of the present invention, the merchant 1 12 accesses the PB store through 
a web site on the web server 214. The PB store module 224 captures the merchant 1 12 actions 
on the web server 214 and creates the appropriate entries in the database 212. 

In one embodiment of the present invention, the PB store web site describes the 

25 payment button mechanism, the services offered by the payment button vendor, and the costs 
of the services. In addition, the web site preferably has a merchant registration form 226 for 
registering new merchants, a merchant renewal form 228 for renewing merchant registrations, 
and a payment button generation form 230 for issuing payment buttons to registered 
merchants. The forms preferably include CGI programs for performing the functionality 

30 described herein. 

The merchant registration form 226 allows the merchant 1 12 to input information 
identifying the merchant 1 12 and includes a payment button with which the merchant 1 12 can 
pay a registration fee. After the fee payment is verified, the merchant 1 12 is preferably issued 
a login/password pair and an account with the CS 1 14 through which the merchant 1 12 can 
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access the payment button generation form and maintain the merchant's account. Similarly, 
the merchant renewal form 228 preferably includes a payment button with which the merchant 
112 can pay a renewal fee. 

The payment button generation form 230 allows the merchant 1 12 to enter item 

5 description data, such as item names and descriptions, prices, types, and delivery options, and 
payment processing rules, such as supported credit cards, payment systems, and currencies. In 
addition, the payment processing rules may rank the payment systems in order of preference, 
describe when payment is required (e.g., the merchant may require billing after 90 days), 
and/or describe the quantity or duration of an item available for a certain price. In one 

10 embodiment of the present invention, the merchant 1 12 enters the item description data and 
payment processing rules by uploading a file to web site having the information in a 
standardized format. 

When entry of this data is completed, the payment button generation form 230 sends 
the data to the transaction engine 210, which stores the information in the database 212 at a 

1 5 location specified by a key. The transaction engine 2 1 0 passes the key back to the PB store 
web site, which provides the merchant with a payment button download page displaying the 
results of the payment button generation transaction. If the transaction was successful, the 
payment button download page includes the payment button issued to the merchant 1 12. The 
payment button has an associated URL that specifies the key. Accordingly, little or no 

20 engineering effort is required to maintain each merchant configuration on the CS 1 14. 

In one embodiment of the present invention, there are multiple PB store web sites 
communicating with the database 212 through the transaction engine 210. When a payment 
button is created, the transaction engine 210 creates a field in the database 212 entry specifying 
the PB store that generated the payment button. Accordingly, payment buttons may be 

25 "branded" among different payment button vendors. 

The database 212 is preferably a robust relational database. A preferred embodiment of 
the present invention uses the ORACLE 7 database to implement the functionality described 
herein. The database 212 stores item descriptions, payment processing rules, and other 
information necessary to complete a payment transaction on behalf of a merchant 1 12. This 

30 merchant information is preferably accessed in the database by using a key assigned to each 
merchant 112 and/or item for sale. The database 212 is also used as a repository of transaction 
information including authorization logs, payment status and completion records, and other 
information required by the merchant 1 12 and the CS 114. 
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FIG. 3 is a high-level block diagram of functional components within the database 212. 
Illustrated therein are a database entry 300 including a primary entry 310 linked to at least one 
of three types of item entries 312, 314, 316. The primary entry 310 is the entry identified by 
the key provided to the merchant 112. Accordingly, the primary entry 3 1 0 is typically 
accessed either when the merchant 112 provides the key while using the PB store web site or 
when the customer 110 uses the URL provided by a payment button to purchase the item 
identified in the database entry 310. 

The primary entry 3 1 0 contains a field 3 1 8 storing the payment processing rules for the 
item as specified by the merchant 1 1 2 through the PB store. The primary entry 310 also 
contains a field 320 holding item type information as specified by the merchant 1 12. The- item- 
type information preferably describes the item attributes input by the merchant 112. In 
addition, the item type information field 320 preferably contains at least one link to another 
database entry 3 1 2, 3 1 4, 3 1 6 describing delivery options for the item. 

The available delivery options for an item depend upon the type of item. FIG. 3 
illustrates three database entries 312, 314, 316 describing delivery options for hard, soft, and 
online items. However, an embodiment of the present invention may have many different 
types of items and corresponding delivery options. A hard item is typically a manufactured 
physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 
holding delivery options 322 may list various shipping methods and companies available for 
delivering the hard item to the customer 1 1 0. 

A soft item, in contrast, is typically intangible intellectual property such as music, 
electronic books, or software. For example, the soft item may be a streaming music file that 
can be played by the customer 110. Accordingly, the entry 314 holding delivery options 324 
may list a URL or electronic key that can be provided to the customer to effectuate the 
purchase. For example, the options 324 may provide instructions for initiating an FTP session 
to download the purchased soft item to the customer's 110 computer system. 

An online item is typically access to an online service or other software executing 
remotely from the customer 1 10. For example, the online item may be access to an electronic 
database of information or an online game. Accordingly, the entry 316 holding delivery 
options 326 preferably includes instructions for allowing the customer 1 10 to access the online 
item. For example, the options 326 may provide instructions for initiating a telnet session with 
an electronic database for a limited duration of time. 

FIG. 4 is a flow diagram illustrating the interactions between the customer 110, 
merchant 1 12, CS 1 14, database 212 and a payment system 222 when completing a payment 
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transaction according to a preferred embodiment of the present invention. In the flow diagram, 
time flows from the top of the diagram to the bottom and horizontal lines represent 
communications between the various entities. FIG. 4 illustrates only major interactions 
between the entities and does not represent every interaction. In addition, FIG. 4 illustrates a 
simple case of the present invention wherein the merchant's 112 payment processing rules 
specify that the payment transaction should be processed at the time the customer's 110 order 
is received. 

Initially, the customer 1 1 0 is browsing the merchant's web site and decides to purchase 
an item by pressing 410 the associated payment button. In response to the press, the 
merchant's web server 112 redirects 412 the customer's browser to the location on the CS 1 14 
specified by the URL associated with the payment button. The customer's browser fetches 414 
the referenced page from the CS 1 14. 

The CS 1 14 parses the URL received from the customer 1 10 for the database 212 key 
corresponding to the item that the customer 1 10 wishes to purchase. Using this key, the CS 
1 14 accesses 416 the database 212 and dynamically generates a web page indicating the 
attributes and payment options available for the item as defined by the merchant 1 12. In 
addition, the CS 1 14 preferably determines the language utilized by the customer 1 10 and 
currencies supported by the merchant 1 12 and modifies the web page accordingly. This 
generated web page is sent 418 to the customer 110. FIG. 5 illustrates an exemplary screen 
display 500 of the web page seeking payment information from the customer 1 10. 

The customer selects the desired item attributes and payment service, enters any 
necessary payment information, such as a credit card or account number, and transmits 420 
these data to the CS 1 14. The CS 1 14 stores 422 the received data in the database 212 and 
contacts the selected payment system 222. As described above, the CS 1 14 preferably uses the 
PAPI module 220 to translate transaction calls made by the transaction engine 210 into the API 
of the selected payment system 222. The CS 1 14 preferably stores 426 records of all 
communications with the payment system 222, customer 1 10, and merchant 1 12 in the 
database 212. Therefore, the database 212 can be used to reconstruct transaction histories in 
order to provide error tracking and accounting services. If the payment system 222 rejects the 
transaction, the CS 1 14 publishes a web page to the customer indicating this result and 
presenting alternative payment methods, if any (this interaction is not shown in FIG. 4). 

If the payment system 222 approves the transaction, the CS dynamically generates a 
web page containing payment status information and publishes 428 this information to the 
customer 110. This page preferably contains a receipt or confirmation number generated by 
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the CS 1 14. In a preferred embodiment of the present invention, the confirmation number is a 
unique number encoding transaction, session, and merchant identifications and a time and date 
stamp. This confirmation number is preferably a key to a database entry holding the 
transaction information and can be used later by the merchant 112 and customer 1 10 to confirm 
5 payment, to query the CS 1 14 for payment status information, and to use the CS 1 14 to query 
the payment system for account status information. The web page also preferably contains any 
other information required by the merchant 1 12 and a link to a confirmation page on the 
merchant's web site 1 12. FIG. 6 illustrates an exemplary screen display 600 of an order 
confirmation web page. 

10 — The GS 1 1 4 also notifies 428 the merchant 1 12 that payment was accepted and provides _ 
the same receipt or confirmation number as was provided to the customer 1 10. In one 
embodiment, this notification is performed via a secure electronic mail message. Accordingly, 
both the customer 110 and merchant 1 12 are notified that the purchase was made. 

Finally, the customer 110 fetches 430 the confirmation web page on the merchant's 

15 web site. Preferably, this web page provides the customer 1 10 with additional information 
about the purchase or any other information which the merchant 112 desires to provide. 

In summary, the present invention is a system, method, and computer program 
instructions for conducting electronic commerce transactions via the Internet or any electronic 
communication system. The merchant 112 opens an account on the CS 1 14 and supplies 

20 information about items sold by the merchant 112. The CS 1 14 stores this information in a 
database 212 entry and. issues the merchant 112 a URL containing the key to database entry. 
The merchant 1 12 supplies this URL to customers wishing to purchase an item, causing a 
customer 1 10 to be connected to the CS 1 14. The CS 1 14 collects payment information from 
the customer 110, conducts the electronic commerce transaction with a remote payment system 

25 222, and notifies the customer 1 10 and merchant 1 12 of the result. 
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Claims 

I claim: 

1 . A computer system for supporting electronic commerce transactions between a 
customer and a remote merchant, the computer system comprising: 

a database having an entry including merchant information identifying an item 

offered for sale by the remote merchant; and 
a transaction engine in communication with the database and a remote payment 

system for performing an electronic commerce transaction, the transaction 

engine comprising: 

a first module for receiving an electronic commerce transaction identifier 

from the customer, the electronic commerce transaction identifier 

specifying the entry in the database; 
a second module for accepting payment information from the customer, the 

payment information identifying the remote payment system; and 
a third module for performing the electronic commerce transaction with the 

remote payment system using the payment information received 

from the customer. 

2. The computer system of claim 1 , wherein the transaction engine further 
comprises: 

a fourth module for notifying the remote merchant and the customer of a result of 
the electronic commerce transaction. 

3. The computer system of claim 1 , further comprising: 

a web server in communication with the transaction engine for communicating with 

the remote merchant and customer; and 
a firewall between the web server and the transaction engine for securing 

communications between the web server and the transaction engine. 

4. The computer system of claim 3, wherein the transaction engine further 
comprises: 

a fifth module for dynamically generating a web page from the entry in the database 
and providing the web page to the customer via the web server, the web 
page providing information about the item offered for sale by the remote 
13 
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merchant and facilitating collection of the payment information from the 
customer. 

5. The computer system of claim 3, wherein the computer system further 
comprises: 

a sixth module for accepting the merchant information identifying the item offered 
for sale by the remote merchant via the web server, creating the database 
entry for holding the merchant information, and providing the remote 
merchant with a reference to the database entry. 

6. The computer system of claim 1 , wherein the electronic commerce transaction 
identifier is a URL identifying the computer system and including a key to the entry in the 
database. 

7. The computer system of claim 1 , wherein the database further comprises: 

an entry specifying payment processing rules defined by the remote merchant; and 
an entry specifying delivery options for the item offered for sale by the remote 
merchant. 

8. The computer system of claim 1, wherein there are a plurality of available 
remote payment systems and wherein the second module for accepting payment information 
from the customer accepts payment information identifying one of the available remote 
payment systems. 

9. The computer system of claim 1 , wherein the transaction engine is executed by 
a plurality of distributed computer systems. 

10. A method of conducting electronic commerce between a remote customer and a 
remote merchant, the method comprising the steps of: 

receiving information identifying an item to be purchased by the remote customer; 
receiving payment information specifying a payment method to be used by the 

remote customer to purchase the item; 
conducting a payment transaction with a remote payment system specified by the 

payment information; and 
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providing the remote customer and the remote merchant with a result of the 
payment transaction, 

1 1 . The method of claim 1 0, further comprising the steps of: 

receiving information about the item to be purchased from the remote merchant; 
5 storing the information about the item to be purchased at a specified location; and 

providing the remote merchant with a reference to the specified location. 

12. The method of claim 1 1 , wherein the remote merchant provides the reference to 
the specified location to the remote customer responsive to the remote customer desiring to 
purchase the item. 

10 13, The method of claim 10, further comprising the step of: 

providing the remote customer with a list of item attributes from which the 
customer can select. 

14. The method of claim 10, wherein the step of receiving information identifying 
the item to be purchased by the remote customer comprises the steps of: 

15 receiving payment processing rules specifying payment options available for 

purchasing the item; and 
receiving delivery options for the item. 

15. A computer- readable medium having computer instructions encoded thereon for 
conducting electronic commerce transactions between a remote merchant and a remote 

20 customer, the computer instructions comprising: 

instructions for storing item information received from the remote merchant; 
instructions for issuing the remote merchant a reference to the stored item 
information; 

instructions for receiving an electronic commerce transaction identifier from the 
25 remote customer containing the reference to the stored item information 

issued to the remote merchant; 
instructions for accepting payment information from the remote customer, the 
payment information identifying a remote payment system; and 
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instructions for conducting the electronic commerce transaction with the remote 
payment system using the payment information received from the remote 
customer. 

16. The computer-readable medium of claim 15, wherein the instructions further 
5 comprise: 

instructions for notifying the remote merchant and the remote customer of a result 
of the electronic commerce transaction. 

1 7. The computer-readable medium of claim 15, wherein the instructions for storing 
item information received from the remote merchant comprise: 

1 0 instructions for receiving payment processing rules from the remote merchant 

specifying payment options for the electronic commerce transaction; and 
instructions for receiving delivery rules from the remote merchant specifying 
■ delivery options for the electronic commerce transaction. 
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netadvantage 



PLEASE REVIEW THIS PAGE AND ENSURE IT IS CORRECT, 
BEFORE COMPLETING YOUR PAYMENT DETAILS. 



PRODUCTS ORDERED 



SKU 
2121 



QTY 
2 



ITEMS UNIT PRICE EXTENDED PRICE 

SPROCKET $8.99 $17.98 
SUBTOTAL: $17.98 
SHIPPING: $ 3.95 
TAX: $ 1-72 

TOTAL: $23.65 



BILLING ADDRESS 



FIRST NAME: 
LAST NAME: 
COMPANY: 
ADDRESS 1: 
ADDRESS2: 
CITY: 
STATE: 
ZIP: 



SHIPPING ADDRESS 



JOE 

BLOGGS 

GLOBAL BAKING COMPANY 
2252 N. PETERS RD. 

SAN JOSE 
CA 

96025-5123 



PAYMENT INFORMATION 



MASTERCARD 



PAYMENT TYPE: 

NAMEAS IT APPEARS ON CARD * = 
NUMBER * ! ■ /■ — =T 
EXPIRATION DATE * I 1/ I ' 
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- - THANK YOU FOR YOUR ORDER - - 
RECEIPT NUMBER: 1587-8029-5 

GLOBAL SPROKETS COMPANY INC. 

2243 E. WISTENA WAY, BOSTON, MA 24248, USA 

EMAIL: INFO@SPROKETS.COM. WEB: HTTP//WWW.SPROKETS.COM 

| PRODUCTS ORDERED ~\ 

SKU QTY ITEMS UNIT PRICE TOTAL PRICE 

2121 2 SPROCKET $8.99 $17.98 

SUBTOTAL: $17.98 

SHIPPING: $ 3.95 

TAX: $ 1.72 

TOTAL: $23.65 



BILLING ADDRESS 



SHIPPING ADDRESS 



FIRST NAME: 
LAST NAME: 
COMPANY: 
ADDRESS 1: 
ADDRESS2: 
CITY: 
STATE: 
ZIP: 



JOE 

BLOGGS 

GLOBAL BAKING COMPANY 
2252 N. PETERS RD. 

SAN JOSE 
CA 

96025-5123 



PAYMENT INFORMATION 



PAYMENT TYPE: MASTERCARD 

YOUR CARD HAS BEEN CHARGED: $23.65 



CUSTOMER INFORMATION 



WE AIM TO SHIP ITEMS WITHIN 10 DAYS 
THANK YOU FOR YOUR ORDER! 
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